DEV Community: 0xSonOfUri

The New Fintech Stack: APIs, Stablecoins, and the Infrastructure Behind Global Money

0xSonOfUri — Fri, 21 Aug 2026 09:45:17 +0000

For decades, building a financial product meant building a significant part of the financial system around it.

If you wanted to create a payments company, you needed banking relationships.

If you wanted customers to receive money, you needed accounts.

If you wanted to move money across borders, you needed access to payment networks, foreign exchange, settlement partners, and liquidity.

If you wanted to build a global product, all of that complexity had to be solved before you could focus on the product itself.

That model is changing.

Today, financial infrastructure is becoming increasingly programmable, composable, and accessible through APIs.

Developers can build on top of infrastructure that handles many of the complicated layers underneath a financial product.

At the same time, stablecoins are introducing another programmable layer for moving value globally.

Together, these changes are creating something that looks increasingly like a new fintech stack.

And the most interesting part isn't simply that the infrastructure is getting better.

It's that more businesses can now build financial products without owning every layer of the financial infrastructure themselves.

The Old Fintech Stack

Historically, financial products were deeply tied to financial institutions.

If you wanted to build a product that moved money, you typically needed to establish relationships with banks and payment providers.

The architecture might have looked something like this:

BANKING SYSTEM
     │
┌────┼────────────┐
│    │            │
Accounts       Payments       FX
│    │            │
└────┼────────────┘
     │
 Settlement
     │
Your Product
     │
 Customer

The product was sitting very close to the underlying financial infrastructure.

That created enormous barriers to entry.

A startup could have an excellent product idea and still spend months or years solving infrastructure problems before reaching meaningful scale.

The challenge wasn't necessarily building the user interface.

The challenge was gaining access to everything behind it.

Financial Infrastructure Was Historically a Moat

This complexity wasn't accidental.

Moving money is difficult.

A financial transaction can involve multiple systems, institutions, currencies, compliance requirements, ledgers, settlement processes, and counterparties.

Even a seemingly simple action like:

"Pay someone $1,000"

can involve significantly more infrastructure underneath.

For example:

Customer
   │
   ▼
Payment Initiation
   │
   ▼
Payment Provider
   │
   ▼
Bank / Financial Institution
   │
   ▼
Clearing
   │
   ▼
Settlement
   │
   ▼
Recipient

Every layer introduces its own requirements.

This meant financial infrastructure itself became a competitive moat.

Companies that already had access to banking relationships and payment networks had a significant advantage over startups trying to build from scratch.

Then APIs Changed Software

We've already seen this transformation happen in another industry.

Cloud computing.

A company building software in the early days of the internet had to think about physical servers, networking, storage, data centers, hardware maintenance, and infrastructure capacity.

Then cloud platforms abstracted much of that complexity.

Developers could request infrastructure through software.

Instead of thinking:

"How do we build and maintain a data center?"

They could think:

"What application do we want to build?"

The infrastructure still existed.

It simply became programmable.

Financial infrastructure is going through a similar transformation.

Financial Infrastructure Is Becoming Programmable

Modern financial infrastructure increasingly exposes financial capabilities through APIs.

Instead of manually coordinating with multiple institutions for every capability, developers can interact with financial infrastructure programmatically.

The conceptual shift looks like this:

BEFORE

Business
   │
   ├── Bank relationship
   ├── Payment provider
   ├── FX provider
   ├── Settlement partner
   └── Treasury infrastructure
            │
            ▼
         Product


AFTER

                    ┌──────────────┐
                    │Infrastructure│
                    │     APIs     │
                    └──────┬───────┘
                           │
                           ▼
                        Product
                           │
                           ▼
                        Customer

The financial infrastructure hasn't disappeared.

It has become a layer that developers can integrate with.

The New Fintech Stack

This leads us to the idea of a new fintech stack.

Instead of thinking about fintech as one enormous system that a company has to build itself, we can think about it as a collection of composable layers.

A simplified version might look like:

┌─────────────────────────────────────┐
│           Customer Experience       │
├─────────────────────────────────────┤
│             Your Product            │
├─────────────────────────────────────┤
│       Financial Application Layer   │
├─────────────────────────────────────┤
│             APIs & SDKs              │
├─────────────────────────────────────┤
│     Payments / Accounts / FX        │
├─────────────────────────────────────┤
│      Settlement & Liquidity         │
├─────────────────────────────────────┤
│       Banking / Financial Rails     │
└─────────────────────────────────────┘

The startup doesn't necessarily need to own every layer.

It can choose which layers to build and which layers to consume.

That distinction is incredibly important.

Build vs. Compose

One of the biggest decisions a fintech founder makes is deciding what to build internally.

You could build everything.

But should you?

A modern software company doesn't build its own database engine, cloud provider, email infrastructure, authentication system, analytics platform, and networking stack before launching its product.

It composes infrastructure.

The same thinking is increasingly applicable to financial products.

Consider a company building a global marketplace.

It needs:

Customer onboarding
Payments
Accounts
Payouts
Currency conversion
Transaction tracking
Settlement
Treasury
Reporting

The company doesn't necessarily need to build a bank.

It needs to build a marketplace.

The financial infrastructure can become a layer beneath that marketplace.

The Financial Primitives

This is where the concept of financial primitives becomes useful.

A primitive is a fundamental capability that can be combined with other capabilities to create something larger.

For financial products, primitives might include:

Accounts
Payments
Payouts
Foreign Exchange
Balances
Transactions
Settlement
Treasury
Stablecoin Transfers

These primitives can then be composed into products.

For example:

             MARKETPLACE
                  │
        ┌─────────┴─────────┐
        │                   │
     Payments            Payouts
        │                   │
        └─────────┬─────────┘
                  │
             Accounts
                  │
             Settlement

The marketplace itself is the product.

The financial primitives are the infrastructure underneath.

Where Afriex Fits

This is where platforms such as Afriex become particularly interesting.

The purpose of financial infrastructure isn't simply to expose APIs.

The larger opportunity is to give businesses access to capabilities they can incorporate into their own products, operations, and workflows.

Instead of every company independently figuring out how to connect financial systems across markets, infrastructure providers can provide a layer through which those capabilities become accessible programmatically.

That changes the question for builders.

Instead of:

"How do I build the entire financial infrastructure?"

the question becomes:

"What financial capabilities does my product need?"

That is a much more interesting problem.

From Infrastructure to Product

Imagine you're building a marketplace.

Your customers don't care which payment infrastructure powers the transaction.

They care that:

They can pay.
Their payment works.
Their money arrives.
They can receive funds.
They can understand their balance.
The experience is fast and reliable.

The customer sees the product.

The infrastructure stays underneath.

                 CUSTOMER
                    │
                    ▼
             Your Marketplace
                    │
                    ▼
          Financial Infrastructure
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
    Payments      Accounts       FX
       │            │            │
       └────────────┼────────────┘
                    ▼
                Settlement

This abstraction is powerful.

The customer doesn't need to understand the infrastructure.

They simply need the experience to work.

The Rise of Stablecoins

Now introduce another major development.

Stablecoins.

Stablecoins are particularly interesting because they combine characteristics of digital assets with relatively stable units of account.

More importantly for developers, they can function as programmable representations of value that can move across blockchain networks.

That creates another potential layer in the global financial stack.

Instead of every movement of value needing to happen through traditional financial rails, stablecoins can sometimes provide another mechanism for moving value between participants and systems.

The architecture can become something like:

Local Currency
      │
      ▼
Payment Infrastructure
      │
      ▼
   Settlement
      │
      ▼
Stablecoin Treasury
      │
      ▼
   Settlement
      │
      ▼
Payment Infrastructure
      │
      ▼
Local Currency

The customer may never see any of this.

From their perspective:

SEND $1,000

Behind the scenes, the infrastructure may involve multiple layers.

That is the point of abstraction.

Stablecoins Don't Replace Everything

It is important not to frame stablecoins as a replacement for the entire financial system.

They are another component of the stack.

A global financial product may still need:

Local payment rails
Banking relationships
Currency conversion
Compliance systems
Settlement
Liquidity
Treasury management
Customer accounts

Stablecoins can fit into that architecture rather than necessarily replacing all of it.

The interesting opportunity is composition.

Traditional Rails
       +
APIs
       +
Stablecoins
       +
Liquidity
       +
Financial Infrastructure
       =
New Financial Products

The Customer Experience Becomes the Abstraction

This is one of the most important changes.

Customers don't want to think about financial infrastructure.

They want to complete an action.

They want to:

Pay

Receive

Send

Withdraw

Convert

The complexity underneath should ideally be invisible.

Consider what a customer might see:

┌──────────────────────────────┐
│                              │
│        Send Money            │
│                              │
│        $1,000                │
│                              │
│        [ Send ]              │
│                              │
└──────────────────────────────┘

What they don't see could be:

Authentication
      ↓
Payment Processing
      ↓
Currency Conversion
      ↓
Liquidity
      ↓
Settlement
      ↓
Treasury
      ↓
Recipient

The best infrastructure makes complicated systems feel simple.

This Is Similar to Cloud Computing

There is a useful analogy here.

Cloud computing didn't eliminate servers.

It abstracted them.

Payment infrastructure doesn't eliminate banks, payment networks, liquidity providers, or settlement systems.

It can abstract access to them.

The developer doesn't necessarily need to know every implementation detail.

They need a reliable interface.

CLOUD

Application
    ↓
Cloud API
    ↓
Servers
    ↓
Networking
    ↓
Data Centers


FINTECH

Financial Product
    ↓
Financial API
    ↓
Payments
    ↓
Settlement
    ↓
Financial Rails

The abstraction layer is what makes the system accessible to a much larger number of builders.

The Developer Becomes a Financial Product Builder

This is perhaps the biggest consequence.

Historically, financial products were primarily built by financial institutions.

Increasingly, software companies can build financial experiences too.

A developer who understands APIs, infrastructure, and product design can potentially build:

Payment platforms
Global marketplaces
Payroll products
Remittance applications
Treasury tools
Creator platforms
B2B payment workflows
Embedded financial experiences

The developer doesn't need to become a bank to understand the product problem.

They need to understand the infrastructure available to them.

A Marketplace Example

Imagine a marketplace connecting businesses in multiple countries.

A traditional approach might look like:

Buyer
  ↓
Marketplace
  ↓
Bank
  ↓
Payment Provider
  ↓
Settlement
  ↓
Seller

Now imagine composing financial infrastructure through APIs.

Buyer
  ↓
Marketplace
  ↓
Financial APIs
  ├── Payment
  ├── Account
  ├── FX
  └── Settlement
        ↓
      Seller

The marketplace can focus on:

Matching buyers and sellers
Product discovery
Pricing
Customer support
Trust
Logistics
User experience

Financial infrastructure becomes one of the services supporting the marketplace.

A Global Payroll Example

Consider another use case.

A company has employees or contractors across several markets.

The product doesn't need to become a bank.

It needs to solve a business problem:

Pay people reliably.

The product could be responsible for:

Employee Management
       ↓
Payroll Calculation
       ↓
Payment Instructions
       ↓
Financial Infrastructure
       ↓
Payout

The company's competitive advantage might be payroll automation, reporting, compliance workflows, or employee experience.

Not the underlying payment rails.

A Remittance Example

Remittance products show why this infrastructure layer matters.

A customer might simply want:

"Send money home."

But the infrastructure underneath may involve:

Sender
  ↓
Collection
  ↓
Currency Conversion
  ↓
Liquidity
  ↓
Settlement
  ↓
Local Payout
  ↓
Recipient

The customer should not have to understand any of those layers.

They should have a simple experience.

That is the promise of abstraction.

Global Businesses Need Global Infrastructure

As businesses become more global, financial infrastructure becomes increasingly important.

A company may begin in one country.

Then it acquires customers elsewhere.

Then it hires internationally.

Then it pays suppliers across borders.

Then it expands into new markets.

Every new market introduces another financial problem.

The old approach was to build another set of integrations.

The newer approach is to use infrastructure that is designed to support multiple financial workflows and markets.

This is where infrastructure becomes a growth enabler rather than simply a technical dependency.

Infrastructure Can Accelerate Distribution

There is another important consequence.

Infrastructure affects how quickly a company can expand.

Suppose a company has discovered strong product-market fit in one market.

Its next challenge is expansion.

If every new market requires rebuilding its financial stack, expansion becomes slow.

But if financial infrastructure is accessible through reusable APIs and standardized workflows, the company can potentially move faster.

The equation changes from:

New Market
    ↓
New Infrastructure
    ↓
New Integrations
    ↓
New Product Work
    ↓
Launch

toward:

New Market
    ↓
Configure Financial Infrastructure
    ↓
Adapt Product
    ↓
Launch

The difference can be significant.

The New Competitive Advantage

This brings us to a larger question.

If infrastructure becomes increasingly accessible, where does the competitive advantage move?

It moves upward.

The infrastructure becomes increasingly standardized.

The product becomes increasingly differentiated.

Consider two companies with access to similar financial primitives.

They could still create completely different products.

One might build:

A global payroll platform.

Another:

A marketplace.

Another:

A remittance product.

Another:

A treasury platform.

The underlying capabilities may overlap.

The customer experience doesn't.

That is where innovation happens.

The Stack Becomes More Modular

The fintech stack increasingly starts to resemble modern software architecture.

Instead of one monolithic system:

┌─────────────────────────────┐
│                             │
│      EVERYTHING IN ONE      │
│          COMPANY            │
│                             │
└─────────────────────────────┘

we get specialized layers:

┌─────────────────────────────┐
│        Your Product         │
├─────────────────────────────┤
│     Financial Workflows     │
├─────────────────────────────┤
│      Infrastructure APIs    │
├─────────────────────────────┤
│ Payments │ FX │ Accounts    │
├─────────────────────────────┤
│ Settlement │ Liquidity      │
├─────────────────────────────┤
│ Banking / Financial Rails   │
└─────────────────────────────┘

Each layer can specialize.

The product builder doesn't need to own everything.

They need to orchestrate the right pieces.

But Abstraction Doesn't Mean Simplicity

There is an important caveat.

Abstracting infrastructure does not eliminate complexity.

It relocates it.

A company building on financial APIs still needs to understand:

Authentication
Security
Transaction states
Error handling
Reconciliation
Compliance requirements
Webhooks
Operational monitoring
Customer support
Financial risk

APIs make infrastructure more accessible.

They don't make financial engineering trivial.

That's an important distinction.

The Responsibility Moves Up the Stack

When infrastructure is abstracted, the responsibility of the product builder changes.

You don't necessarily need to understand every underlying payment rail.

But you absolutely need to understand what your application promises to the customer.

If your product says:

"Your payment has been received."

You need to be certain that it actually has.

If your product says:

"Your money is available."

Your system needs reliable confirmation.

If your product says:

"Your payout has been completed."

You need the underlying financial state to support that claim.

The abstraction layer makes development easier.

It also makes good engineering practices more important.

APIs Are Becoming Financial Building Blocks

The most important shift isn't that APIs exist.

We've had APIs for years.

The shift is that financial capabilities themselves are increasingly exposed as programmable building blocks.

Developers can work with concepts such as:

Customer
Account
Balance
Payment
Transaction
Payout
Exchange Rate
Webhook
Settlement

These aren't just backend resources.

They are building blocks for financial products.

A developer can combine them with:

Authentication
Databases
AI
Analytics
Notifications
Automation

and create an entirely new product.

AI Adds Another Layer

There is another development worth watching.

AI is increasingly becoming an interface for software.

Traditionally:

Human
 ↓
Code
 ↓
API
 ↓
Infrastructure

Now we're beginning to see:

Human
 ↓
AI Agent
 ↓
Tools / APIs
 ↓
Financial Infrastructure

This creates interesting possibilities.

An AI system could potentially help with:

Payment operations
Treasury monitoring
Transaction analysis
Reconciliation workflows
Financial reporting
Operational alerts

The infrastructure still matters.

But the interface for interacting with it is changing.

This is one reason programmable financial infrastructure becomes even more interesting in an AI-native world.

The Financial Stack Is Becoming More Composable

Put all of this together and the picture becomes clearer.

We have:

                 AI / AUTOMATION
                       │
                       ▼
                 YOUR PRODUCT
                       │
                       ▼
              FINANCIAL WORKFLOWS
                       │
         ┌─────────────┼─────────────┐
         ▼             ▼             ▼
      Payments       Accounts        FX
         │             │             │
         └─────────────┼─────────────┘
                       ▼
                  Settlement
                       │
              ┌────────┴────────┐
              ▼                 ▼
        Traditional Rails   Stablecoins
              │                 │
              └────────┬────────┘
                       ▼
                    MONEY

This is what makes the new fintech stack so interesting.

It's no longer one monolithic system.

It's a collection of layers that can be composed.

What This Means for Startups

For founders, this changes what is possible.

You can start with a customer problem.

Then identify the financial capabilities required to solve it.

Then assemble those capabilities.

Instead of beginning with:

"How do we become a financial institution?"

You can begin with:

"What financial experience does our customer need?"

That's a dramatically better starting point.

What This Means for Developers

For developers, the opportunity is equally significant.

The skill set is shifting.

You still need to know how to build software.

But increasingly, you also need to understand how to compose infrastructure.

The developer of the future may not just ask:

"How do I write this API call?"

They'll ask:

"How do I compose these financial primitives into a reliable product?"

That's a higher-level engineering problem.

And potentially a much more valuable one.

What This Means for Financial Infrastructure Providers

For infrastructure providers, the opportunity is to make complexity disappear.

The best infrastructure isn't necessarily the infrastructure with the most features.

It's the infrastructure that lets developers accomplish difficult things without needing to understand every underlying system.

That means:

Good APIs
Clear documentation
Reliable infrastructure
Strong developer tooling
Good observability
Predictable behavior
Easy onboarding

Developer experience becomes part of financial infrastructure itself.

The Future May Be Invisible

The most interesting financial infrastructure may eventually become almost invisible.

A customer won't care whether a payment passed through:

Bank A
→ Payment Provider B
→ Stablecoin C
→ Liquidity Provider D
→ Bank E

They'll simply see:

Payment successful.

The infrastructure becomes invisible.

The product becomes visible.

And that is exactly what good infrastructure is supposed to accomplish.

Where Afriex Fits Into This Future

Platforms such as Afriex are part of this broader transition.

The value isn't simply in providing another financial API.

It's in helping businesses access financial infrastructure that can become part of their own products and operations.

For a builder, that means the financial layer can become something they compose into the product, rather than something they have to build entirely from scratch.

The result is a different kind of fintech architecture:

                    YOUR BUSINESS
                         │
                         ▼
                  YOUR EXPERIENCE
                         │
                         ▼
                 YOUR APPLICATION
                         │
                         ▼
                  AFRIEX INFRASTRUCTURE
                         │
            ┌────────────┼────────────┐
            ▼            ▼            ▼
         Payments      Accounts       FX
            │            │            │
            └────────────┼────────────┘
                         ▼
                    Settlement
                         │
                         ▼
                  Financial Rails

The business owns the customer relationship and product experience.

The infrastructure handles the financial complexity beneath it.

That's the fundamental idea.

The Biggest Shift Isn't Technology

It is tempting to look at all of this as a technology story.

APIs.

Cloud infrastructure.

Stablecoins.

AI.

Automation.

But underneath all of those technologies is a much bigger shift:

Who gets to build financial products?

If financial infrastructure becomes increasingly accessible through APIs, then the answer is no longer simply:

Banks and large financial institutions.

It becomes:

Software companies, startups, developers, and businesses that know how to compose the infrastructure.

That's a profound change.

From Owning Infrastructure to Composing Infrastructure

The previous generation of fintech often competed on infrastructure ownership.

The next generation may increasingly compete on infrastructure composition.

The question becomes:

What can you combine?

Not:

What can you build entirely yourself?

That distinction matters.

Because building everything is expensive.

Composing the right infrastructure can be much faster.

The New Fintech Stack

So if we zoom out, the new fintech stack looks something like this:

┌──────────────────────────────────────┐
│              EXPERIENCE              │
│          What customers see          │
├──────────────────────────────────────┤
│               PRODUCT                │
│       Business logic & workflows     │
├──────────────────────────────────────┤
│          FINANCIAL APIS              │
│ Accounts • Payments • FX • Payouts  │
├──────────────────────────────────────┤
│         FINANCIAL INFRASTRUCTURE     │
│      Settlement • Liquidity • Rails  │
├──────────────────────────────────────┤
│          PROGRAMMABLE VALUE          │
│              Stablecoins              │
├──────────────────────────────────────┤
│          TRADITIONAL SYSTEMS         │
│        Banks • Networks • Rails      │
└──────────────────────────────────────┘

And increasingly, AI and automation can sit across the entire stack.

The result is a financial ecosystem that is more modular than the one that came before it.

The Opportunity for Builders

This is what makes the current moment particularly exciting.

A developer with a good idea doesn't necessarily need to start by building a bank.

A founder doesn't necessarily need to own every payment rail.

A marketplace doesn't necessarily need to create its own settlement network.

A payroll company doesn't necessarily need to build banking infrastructure.

A remittance startup doesn't necessarily need to recreate the entire global financial system.

They need to identify the problem.

Then compose the infrastructure required to solve it.

Final Thoughts

The fintech industry is moving toward a model that looks increasingly familiar to anyone who has built modern software.

Infrastructure is becoming modular.

Capabilities are becoming programmable.

APIs are becoming the interface between businesses and financial systems.

Stablecoins are introducing new ways to move programmable value.

AI is creating new ways to interact with software.

And infrastructure providers are abstracting more of the complexity that once required direct ownership and deep institutional relationships.

The result is a new fintech stack.

One where the underlying financial infrastructure can increasingly become a building block.

And that changes the opportunity for builders.

The question is no longer simply:

"How do we build the financial infrastructure?"

It's becoming:

"What can we build because the infrastructure is already there?"

That is where things get interesting.

Because the next generation of fintech products may not be built by companies that own every financial rail.

They may be built by companies that know how to compose the rails into something customers actually want.

The infrastructure is becoming programmable.

The money is becoming programmable.

Now the opportunity is to build what comes next.

I Built an Afriex MCP Prompt Cookbook So Developers Never Have to Stare at a Blank Prompt Again

0xSonOfUri — Sun, 21 Jun 2026 00:17:23 +0000

A few weeks ago, I started exploring the Afriex MCP server.

The setup was surprisingly straightforward.

Connect your MCP client.
Configure your API key.
Verify the connection.

Done.

But then I ran into a different problem.

Not a technical problem.

A prompt problem.

The Blank Prompt Problem

Once everything was connected, I found myself staring at an empty prompt box.

What should I ask?

Sure, I could retrieve balances.

I could create customers.

I could generate virtual accounts.

But what were the most useful workflows?

What were the prompts that would actually help developers build real products?

This isn't a problem unique to Afriex.

It's becoming a common challenge across the entire MCP ecosystem.

The infrastructure exists.

The tools work.

But many developers don't know where to start.

MCP Changes How We Build

Traditionally, integrating a payment API looked something like this:

Read documentation
Find the endpoint
Write HTTP requests
Parse responses
Build business logic

With MCP, the workflow looks very different.

You can simply tell your AI assistant what you want to build.

For example:

Create a customer onboarding flow that:

- Collects customer details
- Generates a virtual account
- Displays payment instructions

Build it using Next.js and TypeScript.

Instead of manually stitching everything together, the AI can interact with infrastructure through the MCP server.

That's incredibly powerful.

But only if you know what to ask.

The Idea

That's what led me to build the:

Afriex MCP Prompt Cookbook

A collection of practical, production-oriented prompts designed specifically for developers building with Afriex MCP.

The goal is simple:

Copy.

Paste.

Build.

Instead of starting from scratch every time.

The cookbook is open source and available on GitHub:

https://github.com/SonOfUri/afriex-mcp-cookbook

Feel free to explore the prompts, use them in your own projects, and contribute new recipes.

What's Inside

The cookbook is organized around real-world use cases.

Not API endpoints.

Not documentation pages.

Actual products and workflows.

Getting Started

For developers who have just connected their MCP client.

Examples include:

Retrieving balances
Creating customers
Monitoring transactions

Virtual Accounts

Examples include:

Customer onboarding flows
Collections systems
Payment request workflows

Payments

Examples include:

Payment links
Payout systems
Payment status tracking

Stablecoins

Examples include:

USDC deposit flows
Treasury monitoring
Settlement operations

AI Agents

Examples include:

Operations agents
Treasury agents
Monitoring agents

OpenClaw Integrations

Examples focused on combining AI agents with payment infrastructure.

My Favorite Prompt

One of my favorite recipes asks Cursor to build an entire virtual account collection flow.

Using Afriex MCP:

Create a customer onboarding flow that:

- Collects customer details
- Creates a customer record
- Generates a virtual account
- Displays payment instructions

Build this as a modern Next.js application using TypeScript and TailwindCSS.

Show me the complete implementation.

This is the kind of workflow that would traditionally require:

reading documentation
understanding endpoints
designing data models
wiring API calls

Now it can start with a single prompt.

Why I Think Prompt Libraries Matter

We're entering a new phase of software development.

Documentation remains important.

SDKs remain important.

APIs remain important.

But prompts are becoming a new layer of developer experience.

The best developer platforms won't just provide endpoints.

They'll provide examples, recipes, workflows, and patterns that help developers move from idea to implementation faster.

That's exactly what this cookbook is trying to do.

What Comes Next

The current version focuses on:

payments
virtual accounts
stablecoins
AI agents
OpenClaw integrations

Future additions will include:

more production workflows
community-contributed recipes
example applications
advanced MCP patterns

Final Thoughts

One of the most surprising lessons I've learned while working with MCP is that access to tools isn't enough.

Developers also need examples of what's possible.

That's what the Afriex MCP Prompt Cookbook aims to provide.

Not more documentation.

Not another SDK.

A collection of practical prompts that help developers build faster.

Because sometimes the hardest part isn't connecting the infrastructure.

It's knowing what to ask next.

Explore The Cookbook

GitHub:

https://github.com/SonOfUri/afriex-mcp-cookbook

If you're building with Afriex MCP, I'd love to see what you create and what prompts you find most useful.

Contributions, suggestions, and new recipes are always welcome.

Building Global Payment Products Without Owning Banking Infrastructure

0xSonOfUri — Fri, 12 Jun 2026 23:46:55 +0000

A decade ago, building a financial product required enormous resources.

If you wanted to launch a payments company, you needed:

banking relationships
settlement infrastructure
compliance operations
payment processing agreements
treasury management systems

For most startups, that was simply out of reach.

Today, things look very different.

A small team can build products that move money globally without owning a bank, operating payment rails, or maintaining treasury infrastructure.

The secret isn't magic.

It's infrastructure.

The Old Fintech Playbook

Historically, launching a financial product meant becoming part of the financial system itself.

That often involved:

obtaining licenses
negotiating banking partnerships
integrating with payment processors
maintaining settlement accounts
building compliance operations

The barriers were high.

And for good reason.

Moving money is complicated.

The New Fintech Stack

Modern fintech companies increasingly build on top of specialized infrastructure providers.

Instead of building everything themselves, they compose financial primitives.

Think of it like cloud computing.

Most startups don't build their own data centers.

They build on AWS, Google Cloud, or Azure.

Financial infrastructure is moving in a similar direction.

Developers now have access to building blocks such as:

virtual accounts
wallet infrastructure
payouts
foreign exchange
stablecoin settlement
transaction monitoring

through APIs.

The Shift from Banks to Building Blocks

Consider a simple requirement:

Receive money from customers.

Years ago, that might require:

direct banking integrations
account provisioning systems
settlement infrastructure

Today, an API can provision receiving accounts for you.

The same pattern appears across the financial stack.

Need to:

receive funds?
send payouts?
manage wallets?
support multiple currencies?

There are infrastructure layers designed to handle those complexities.

What Developers Actually Build

The interesting thing is that most fintech startups are not building payment rails.

They're building products.

The rails already exist.

The real value often comes from:

user experience
automation
workflows
business logic
distribution

Not from rebuilding banking infrastructure.

For example:

A freelancer platform doesn't need to become a bank.

It needs:

customer onboarding
collections
payouts
reporting

Infrastructure providers handle the rest.

The Role of Stablecoins

Stablecoins are accelerating this trend.

Many cross-border payment platforms now use stablecoins internally for:

treasury management
liquidity movement
settlement

while customers continue interacting with familiar payment experiences.

The customer sees:

Send Money

The infrastructure may involve:

Collection
↓
Settlement
↓
Stablecoin Treasury
↓
Liquidity Partner
↓
Payout

The complexity is hidden behind APIs and infrastructure layers.

What This Means for Builders

The question is no longer:

How do I become a bank?

The question is:

What can I build on top of financial infrastructure?

That opens the door to entirely new products.

Developers can focus on:

marketplaces
payroll systems
creator platforms
remittance products
B2B payment workflows
treasury automation

without spending years building foundational infrastructure.

Infrastructure Is Becoming the Advantage

The most successful fintech companies of the next decade may not be the ones that own the rails.

They may be the ones that use the rails most effectively.

Just as cloud providers abstracted away servers, modern financial infrastructure is abstracting away much of the complexity involved in moving money.

That allows builders to focus on solving customer problems rather than rebuilding the financial system from scratch.

Final Thoughts

Building a global payment product used to require becoming part of the banking system.

Today, developers can access many of the same capabilities through infrastructure providers and APIs.

The opportunity has shifted.

Less time spent building rails.

More time spent building products.

And that might be one of the most important changes happening in fintech today.

What Happens After You Click “Send Money”? Lessons from the Afriex Utila Partnership

0xSonOfUri — Fri, 29 May 2026 15:42:42 +0000

Most people think cross-border payments are simple.

You open an app.

Enter an amount.

Choose a recipient.

Click send.

A few moments later, the money arrives.

Simple.

At least on the surface.

What most people never see is the infrastructure required to make that experience possible at scale.

Recently, Utila published a case study about its partnership with Afriex, a company operating cross-border payment corridors across Africa. While the announcement focused on infrastructure, it revealed something much more interesting:

The real challenge in cross-border payments isn't sending money. It's managing liquidity, treasury operations, and settlement across multiple markets simultaneously.

And that's where stablecoins are quietly becoming critical infrastructure.

The Hidden Side of Cross-Border Payments

When users think about a transfer, they typically imagine something like this:

Sender
   ↓
Payment
   ↓
Recipient

Reality looks closer to:

Sender
   ↓
Collection Rail
   ↓
Treasury Layer
   ↓
Liquidity Partner
   ↓
FX Conversion
   ↓
Settlement Layer
   ↓
Local Payout Partner
   ↓
Recipient

Every additional country introduces more complexity:

different currencies
different banking systems
different payout partners
different liquidity requirements

Now imagine operating this across more than 20 African corridors.

The challenge quickly becomes operational.

Afriex's Challenge

According to Utila's case study, Afriex needed the ability to support multiple stablecoins across multiple blockchain networks while settling with payout partners throughout Africa.

The problem wasn't simply storing assets.

It was managing:

USDC
USDT
multiple blockchain networks
treasury movements
partner settlements
growing B2B customer operations

all from a unified operational layer.

Without consolidation, these workflows often require:

multiple exchanges
multiple wallets
manual treasury processes
fragmented operational visibility

As transaction volume grows, that model becomes increasingly difficult to manage.

Why Stablecoins Matter

When most people hear "stablecoins," they think about crypto.

But infrastructure teams increasingly think about them differently.

They think about settlement.

Stablecoins offer something traditional payment systems often struggle to provide:

global interoperability
24/7 settlement
programmable transfers
asset portability across networks

For payment companies, stablecoins are increasingly functioning as operational rails rather than speculative assets.

That's a significant shift.

The Infrastructure Layer

One detail from the case study stood out.

Afriex needed to support:

any stablecoin on any chain

for partner settlements across African markets.

That sounds simple.

It isn't.

Different counterparties may require:

different assets
different networks
different settlement preferences

Supporting that flexibility often introduces substantial operational complexity.

According to the case study, Utila provided a single platform that enabled:

multi-asset support
multi-chain support
treasury operations
wallet provisioning
settlement workflows

from one operational layer.

The result was less fragmentation and greater operational control.

Beyond Treasury: Wallet Infrastructure

Another interesting outcome was wallet provisioning.

As Afriex expanded its B2B platform, business customers needed dedicated wallet infrastructure.

Rather than treating wallets as an internal treasury tool, wallets became part of the customer-facing product experience.

Businesses could receive:

dedicated wallet addresses
preferred stablecoin support
preferred network support

while Afriex managed the infrastructure centrally.

This highlights an important trend:

Stablecoin infrastructure is increasingly becoming product infrastructure.

The Bigger Trend

The Afriex × Utila story reflects a broader industry movement.

Stablecoins are no longer only consumer products.

They are becoming:

treasury infrastructure
settlement infrastructure
liquidity infrastructure
payment infrastructure

Across the payments industry, companies are increasingly evaluating stablecoins as an alternative settlement layer because of their speed, global accessibility, and operational flexibility.

In many ways, stablecoins are evolving into the backend infrastructure powering modern money movement.

Users may never see them.

But they increasingly benefit from them.

The Real Lesson

The most interesting takeaway from the Afriex × Utila partnership isn't that a fintech adopted stablecoins.

It's that operational complexity becomes the biggest challenge as payment systems scale.

Building a payment product is one thing.

Operating liquidity, settlements, treasury, and customer infrastructure across dozens of markets is another challenge entirely.

The companies that succeed are often the ones that find ways to simplify that complexity.

That's what makes this case study interesting.

It's a reminder that behind every successful payment experience is an enormous amount of infrastructure working quietly in the background.

Final Thoughts

Cross-border payments are often discussed from the perspective of user experience.

Faster transfers.

Lower fees.

Better access.

But infrastructure tells a different story.

The real challenge is coordinating liquidity, settlements, treasury operations, and customer assets across a fragmented financial landscape.

The Afriex × Utila partnership offers a glimpse into how modern payment companies are approaching that challenge.

And increasingly, stablecoins are becoming part of the answer.

What Happens When AI Agents Can Access Payment Infrastructure? Exploring OpenClaw + Afriex MCP

0xSonOfUri — Fri, 29 May 2026 15:24:25 +0000

For years, we've built APIs for developers.

Every payment gateway, banking platform, fintech API, and infrastructure provider has been designed around a simple assumption:

A human developer writes the code that interacts with the API.

But what happens when AI agents become the users of those APIs?

That's the question I've been thinking about while exploring OpenClaw and Afriex MCP.

Not from the perspective of replacing developers.

But from the perspective of enabling AI systems to interact with infrastructure in meaningful ways.

The Shift From Code Generation to Infrastructure Interaction

Most developers have already experienced AI-assisted coding.

We use tools like Cursor to:

generate components
write tests
explain code
scaffold projects

But that's still fundamentally code generation.

The AI helps create software.

The developer remains the bridge between the software and the infrastructure.

The next evolution is different.

The AI doesn't just generate code.

The AI interacts with infrastructure directly.

Enter OpenClaw

OpenClaw is an open framework for building AI agents capable of interacting with tools and external systems.

Instead of simply responding to prompts, agents can:

perform actions
execute workflows
use tools
interact with services

This transforms the AI from a conversational assistant into something much more operational.

The interesting question becomes:

What tools should these agents have access to?

And that's where infrastructure enters the picture.

Enter Afriex MCP

Afriex MCP exposes Afriex capabilities through the Model Context Protocol.

This means AI-enabled tools and agents can interact with payment infrastructure through structured tooling.

Instead of building everything manually first, an agent can understand and interact with financial primitives such as:

balances
virtual accounts
transactions
payment workflows

through MCP-enabled interfaces.

On their own, OpenClaw and Afriex MCP are interesting.

Together, they become much more compelling.

What Could an Infrastructure-Aware Agent Do?

Imagine an AI agent with access to payment infrastructure.

Not in a hypothetical science-fiction future.

Today.

Balance Monitoring

An agent could continuously monitor balances across accounts.

When thresholds are reached, it could:

notify teams
trigger workflows
generate reports

without manual intervention.

Payment Operations

An agent could generate receiving instructions for customers.

For example:

Create a virtual account for Customer X.

The agent retrieves the required information and returns payment instructions immediately.

Transaction Monitoring

Instead of manually checking dashboards, agents could monitor transaction events and surface only what requires human attention.

Examples:

failed transactions
delayed settlements
unusual activity
reconciliation issues

Developer Workflows

This is the area that excites me most.

Imagine asking:

Generate a payment integration using Afriex.

Instead of simply generating generic code, the agent understands:

the infrastructure
available tools
workflow patterns

and builds with real context.

The difference is subtle.

But significant.

APIs Were Built for Developers

One idea keeps coming back to me.

For decades, we've designed APIs around human developers.

Documentation.
SDKs.
Authentication.
Request-response patterns.

Everything assumes a human sits in the middle.

But MCP introduces a different model.

Infrastructure becomes accessible not only to developers, but also to AI systems.

That changes how we think about integrations.

It changes how we think about tooling.

And eventually, it may change how software gets built.

Why Fintech Is Particularly Interesting

Many industries can benefit from infrastructure-aware agents.

Fintech stands out because financial workflows are already highly structured.

Consider how much time teams spend:

monitoring transactions
checking balances
reconciling payments
handling operational workflows

These are precisely the kinds of activities agents can assist with.

Not replacing humans.

Augmenting them.

Making teams more efficient.

Reducing operational friction.

The Bigger Picture

I don't think the most interesting outcome is:

AI writes code faster.

I think the more interesting outcome is:

AI understands and interacts with infrastructure.

That's a much bigger shift.

Because once agents can interact with infrastructure safely and predictably, entirely new workflows become possible.

OpenClaw provides the agent layer.

Afriex MCP provides the infrastructure layer.

Together they offer a glimpse into what AI-native financial systems might look like.

Final Thoughts

We're still early.

Most of these patterns are only beginning to emerge.

But one thing feels increasingly clear:

The future isn't just AI-assisted development.

It's infrastructure-aware AI.

And as developers, it's worth paying attention to what becomes possible when agents can interact with the systems we've spent years building.

OpenClaw and Afriex MCP are an interesting place to start exploring that future.

Getting Started with Afriex MCP in Cursor

0xSonOfUri — Sat, 16 May 2026 15:17:52 +0000

AI coding tools are evolving quickly.

But the real shift starts when your editor can interact with infrastructure directly.

Instead of only generating code, AI tools can now:

query APIs
interact with services
retrieve live data
execute workflows

That’s where MCP comes in.

In this guide, you’ll learn how to:

set up Afriex MCP in Cursor
connect your Afriex account
verify your setup
understand how MCP changes the developer workflow

This is not a product demo.

This is a practical setup guide for developers getting started with Afriex MCP.

What is MCP?

MCP (Model Context Protocol) is a standardized way for AI tools to interact with external systems and services.

Instead of treating the AI editor as:

“just a code generator”

MCP allows it to become:

“an infrastructure-aware development environment”

With MCP, AI tools can:

access APIs
call external tools
retrieve live data
orchestrate workflows

directly from inside the editor.

Why This Matters

Normally, integrating financial infrastructure involves:

reading documentation
wiring SDKs manually
testing requests
switching between dashboards and terminals

With MCP:

the editor gains context
workflows become faster
AI can assist with infrastructure interactions directly

This creates a very different developer experience.

What is Afriex MCP?

Afriex MCP exposes Afriex infrastructure capabilities to AI-enabled developer tools like Cursor.

This allows Cursor to:

retrieve balances
understand payment workflows
scaffold integrations
interact with Afriex APIs through MCP tools

directly from natural language prompts.

Prerequisites

Before starting, you’ll need:

An Afriex Business account
Cursor installed
An Afriex API key

Useful links:

Step 1 — Log Into Afriex Business

Head to:

https://business.afriex.com/

Log into your Afriex Business account.

Step 2 — Open the Documentation

Inside the dashboard:

Navigate to:
- Developer
- API Documentation

Afriex provides detailed developer documentation including MCP setup instructions.

Step 3 — Open the MCP Guide

Inside the docs:

Open:
- MCP Server
- Connecting MCP Clients

This section contains:

supported MCP clients
setup instructions
recommended configurations

Step 4 — Select Cursor

Afriex supports multiple MCP-capable tools and IDEs.

In this guide, we’ll use:

Cursor

Copy the recommended Cursor MCP configuration from the docs.

Step 5 — Configure Cursor

Inside Cursor:

Open Settings
Navigate to:
- Tools & MCPs
Click:
- Add Custom MCP

Paste the configuration you copied from the Afriex documentation.

Step 6 — Update Your Credentials

Update the configuration with your credentials:

"x-afriex-api-key": "YOUR_API_KEY",
"x-afriex-environment": "production"

You can also use:

"x-afriex-environment": "sandbox"

for testing environments if supported in your workflow.

Step 7 — Verify the Connection

Now that Cursor is connected to Afriex MCP, try a simple prompt inside Cursor:

Use Afriex MCP to fetch my live balances

If everything is configured correctly, Cursor should retrieve:

NGN balances
USD balances
supported wallet balances

directly from Afriex.

At this point, your editor is no longer operating purely as a code assistant.

It can now interact with infrastructure through MCP.

What Makes This Interesting

The important shift here is not:

“AI generates code.”

The interesting part is:

“AI can now interact with systems.”

That changes the workflow significantly.

Instead of:

constantly context switching
manually wiring everything first
navigating infrastructure alone

developers can now work with AI tools that understand:

APIs
infrastructure
workflows
integrations

more directly.

Example MCP Workflow

Once connected, you can start using prompts like:

Fetch my Afriex balances

Help me scaffold an Afriex integration

Generate a Next.js API route for Afriex virtual accounts

Create a webhook handler for Afriex payment events

The AI editor now has context about:

the infrastructure
the available tools
the integration patterns

which makes the development experience much smoother.

Security Notes

When using MCP integrations:

never expose your API keys publicly
avoid committing credentials to Git repositories
use environment variables where possible
rotate keys periodically

Treat your MCP configuration with the same care as production infrastructure credentials.

Where This Goes Next

Afriex MCP opens up workflows around:

payments
virtual accounts
payouts
reconciliation
infrastructure automation
fintech developer tooling

And this is still early.

As MCP ecosystems evolve, developer tools will become increasingly:

infrastructure-aware
execution-aware
workflow-aware

Final Thoughts

Setting up Afriex MCP inside Cursor only takes a few minutes.

But the implications are much bigger.

We’re moving toward a world where AI editors:

understand infrastructure
interact with APIs
assist with integrations
help orchestrate real systems

not just generate snippets.

And honestly, that changes how software gets built.

Resources

Afriex Business

https://business.afriex.com/

Afriex Documentation

https://docs.afriex.com/

Cursor

https://cursor.com/

Get Paid Globally, Without a Website with Loop(Built with MeDo)

0xSonOfUri — Wed, 06 May 2026 19:09:59 +0000

Getting paid globally is still harder than it should be.

If you’re a freelancer or small business owner, you often need:

a website
a payment processor
multiple tools for different payment methods

And even then, it’s fragmented.

So I asked a simple question:

What if getting paid globally was as easy as sending a link?

That’s how LOOP was born.

💡 What is LOOP?

LOOP is a simple payment tool that lets you:

→ Create a payment link
→ Share it with anyone
→ Get paid globally

No website required.

⚙️ What LOOP Can Do

Create invoices with multiple items
Generate shareable payment links
Accept payments via:
- Card
- Bank transfer
- Crypto (USDT / USDC)
Show real-time currency conversion
Generate downloadable receipts
Track transactions and balances
Send and receive memos
Get real-time notifications

🌍 Why This Matters

Many people across emerging markets don’t have:

websites
payment infrastructure
access to global payment systems

LOOP removes that barrier completely.

You just:

create → share → get paid

🛠️ How I Built It

I built LOOP using MeDo, an AI-powered application generation platform.

Instead of manually coding everything, I focused on:

product flow
user experience
system design

Key pieces:

React + Tailwind + shadcn (via MeDo)
Modular services:
- paymentService
- walletService
- transactionService
Dynamic payment links (/pay/[id])
Multi-payment simulation:
- card
- bank
- crypto

🔌 Using Plugins (ExchangeRate)

To make LOOP truly global, I integrated the ExchangeRate plugin.

This powers:

a currency converter widget
real-time conversion inside invoices

Example:

$50 ≈ ₦75,000

This helps both businesses and customers understand value instantly.

🧠 Key Challenges

1. Making it feel real without real payments

I had to simulate:

payment processing
confirmations
receipts

Without using actual payment APIs.

2. State persistence

Initially, everything reset on refresh.

Fix:
→ implemented local storage persistence
→ made the app feel like a real system

3. UX simplicity vs feature depth

I had to constantly balance:

powerful features vs
a simple user flow

🚀 What’s Next

Real payment integrations (bank APIs, crypto rails)
Authentication & multi-user support
Recurring payments
Advanced invoicing

🎥 Demo

Check out the full demo here:

Try the app:

LOOP Checkout

app-bd1hkbkbf7r5.appmedo.com

🧵 Final Thought

Building LOOP showed me that:

Great products aren’t about complexity — they’re about removing friction.

Built for the MeDo Hackathon

BuiltWithMeDo

Accept USDC / USDT Without Running Your Own Wallet Infrastructure (Afriex API)

0xSonOfUri — Mon, 20 Apr 2026 12:08:15 +0000

Stablecoins are becoming core infrastructure for global payments.

But building with them usually means:

managing private keys
running indexers
tracking on-chain activity

That’s a lot of overhead.

In this guide, you’ll learn how to accept USDC / USDT without running your own custody infrastructure, using the Afriex API.

What You’ll Build

A backend endpoint that returns deposit instructions (address + network)
A webhook system to confirm payments reliably
A production-ready flow using idempotency and retries-safe logic

The Mental Model

Stop thinking:

“I need to manage wallets”

Start thinking:

“I’m building on payment rails”

With Afriex:

You don’t generate private keys
You don’t run blockchain infrastructure
You rely on Afriex for:
- deposit attribution
- transaction state
- settlement

Your job is to:

create a payment / invoice object
show deposit instructions
confirm payments via webhooks

Step 0 — Setup API Access

Base URLs

Sandbox: https://sandbox.api.afriex.com
Production: https://api.afriex.com

Environment Variables

AFRIEX_API_BASE_URL="https://api.afriex.com"
AFRIEX_API_KEY="your-api-key"
AFRIEX_WEBHOOK_PUBLIC_KEY="your-public-key"

Example Request

curl -sS -G "https://api.afriex.com/api/v1/org/balance" \
  -H "x-api-key: YOUR_AFRIEX_API_KEY"

Step 1 — Create Your Payment Object

Afriex does not create payment links for you.

You define your own invoice / payment intent:

{
  id: "internal_id",
  reference: "unique_reference",
  asset: "USDC",
  amount: 100,
  status: "pending",
  expiresAt: Date
}

Tip: Make reference globally unique and reuse it across retries.

Step 2 — Get Deposit Address

Endpoint

GET /api/v1/payment-method/crypto-wallet

Example

curl -sS -G "https://api.afriex.com/api/v1/payment-method/crypto-wallet" \
  -H "x-api-key: YOUR_API_KEY" \
  --data-urlencode "asset=USDC"

Response

{
  "data": [
    { "address": "0x...", "network": "ETHEREUM_MAINNET" },
    { "address": "TY...", "network": "TRON_MAINNET" }
  ]
}

Backend Example

const wallet = await fetch(url).then(res => res.json())

const preferred =
  wallet.data.find(w => w.network === "ETHEREUM_MAINNET") ??
  wallet.data[0]

return {
  address: preferred.address,
  network: preferred.network,
  asset: "USDC"
}

Important Note

This endpoint is:

Production only

It does not work in sandbox.

Step 3 — Display Payment Instructions

Your UI should show:

Asset (USDC / USDT)
Network
Address (copy + QR)

Also include:

Sending on the wrong network may result in lost funds

Step 4 — Confirm Payments (Webhooks)

This is the most important part.

Do NOT:

rely on user confirmation
rely on block explorers

Use Afriex webhooks.

Webhook Setup

Configure your webhook URL in the dashboard
Copy your webhook public key
Allowlist Afriex IPs

Signature Verification

import crypto from "crypto"

function verifySignature(signature, rawBody, publicKey) {
  const verifier = crypto.createVerify("RSA-SHA256")
  verifier.update(rawBody)
  return verifier.verify(publicKey, signature, "base64")
}

Important: verify the raw request body, not parsed JSON.

Events

TRANSACTION.CREATED
TRANSACTION.UPDATED

Logic

if (event === "TRANSACTION.UPDATED" && status === "SUCCESS") {
  markInvoiceAsPaid()
}

Ensure this operation is idempotent.

Step 5 — Idempotency

Outbound

Use:

{
  "meta": {
    "reference": "invoice_123",
    "idempotencyKey": "idem_invoice_123"
  }
}

Inbound

Webhooks may retry.

Ensure:

no duplicate credits
safe re-processing

Use database constraints or “update-if-not-paid” logic.

Step 6 — Reconciliation

Use Afriex APIs for support and debugging:

Get transaction
List transactions
Get balance

⚠️ Common Pitfalls

1. Crypto Wallet Not Working in Dev

→ It’s production only

2. Wrong Network Deposits

→ Only present one supported network

3. Webhook Verification Fails

→ Use raw body + correct public key

4. Duplicate Credits

→ Fix with idempotency

Why This Matters

Stablecoins are becoming:

Core rails for global payments

The real opportunity isn’t just using them.

It’s building systems on top of them.

Summary

With Afriex, you can:

Accept USDC / USDT
Avoid custody complexity
Use webhooks for reliable confirmation
Build production-ready payment systems

Final Thought

Afriex gives you the rails.

You build the product.

Getting Started with the Afriex API: From Signup to Your First Request

0xSonOfUri — Tue, 07 Apr 2026 12:00:48 +0000

What if you could start building global payment systems in minutes?

Before you can build payment links, payouts, or crypto flows — you need access to the Afriex API.

This guide walks you through going from zero → your first API call.

What You’ll Do

By the end of this guide, you’ll:

Create an Afriex Business account
Complete onboarding and verification
Generate your API key
Make your first API request

Step 1: Create an Afriex Business Account

Head to:

https://business.afriex.com/

Step 2: Select Entity Type

Choose the entity that applies to you:

Sole Trader / Sole Proprietorship → if you're an individual
Registered Company / Corporate → if you're a company

This determines the documents required during verification.

Step 3: Set Up Your Business

Fill in your details:

Phone number
Full name
Business name
Country of residence
Password

Step 4: Complete Verification

To unlock full API access, you’ll go through verification:

Provide company details
Upload documents
Add associated parties
Complete phone verification

This is required for compliance and security.

Step 5: Set Up Your Team (Optional)

From the dashboard, you can:

Add team members
Assign roles
Manage permissions

Useful if you're building with others.

Step 6: Generate Your API Key

Once your account is ready:

Go to Settings → API Keys
Generate a new key
Store it securely

Never expose your API key in frontend code or public repositories.

Step 7: Make Your First API Call

Now let’s test the API.

Create a Customer

curl -X POST https://sandbox.api.afriex.com/api/v1/customer \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{
    "fullName": "John Doe",
    "email": "john.doe@example.com",
    "phone": "+2348192837465",
    "countryCode": "NG"
  }'

Expected Response

{
  "data": {
    "customerId": "69516dd0464b2213bd74cfad",
    "fullName": "John Doe",
    "email": "john.doe@example.com",
    "phone": "+2348192837465",
    "countryCode": "NG"
  }
}

Step 8: Process Your First Transaction

Once you have a customer, you can initiate a transaction:

curl -X POST https://sandbox.api.afriex.com/api/v1/transaction \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{
    "customerId": "CUSTOMER_ID",
    "type": "WITHDRAW",
    "sourceAmount": "10",
    "destinationAmount": 5000,
    "sourceCurrency": "USD",
    "destinationCurrency": "NGN",
    "destinationId": "PAYMENT_METHOD_ID"
  }'

Important Notes

Use the sandbox environment for testing
Switch to https://api.afriex.com for production
Keep your API key secure
Always make API calls from your backend

Explore the Docs

https://docs.afriex.com/

You can also fetch the full index here:
https://docs.afriex.com/llms.txt

What Next?

Now that you have access, you can start building:

Payment links
Cross-border payouts
Crypto integrations
Multi-currency systems

Next guide: Send a Link, Get Paid: Building Payment Links with the Afriex API

Final Thought

Afriex gives you the rails.

You just made your first step into building on top of them.

Send a Link, Get Paid: Building Payment Links with Afriex

0xSonOfUri — Mon, 30 Mar 2026 17:45:56 +0000

Send a Link, Get Paid: Building Payment Links with the Afriex API

What if you could accept payments globally with just a link?

No checkout flows. No heavy integrations. Just a URL.

What This Guide Covers

This guide is about the Afriex API.

You’ll learn how to build a simple payment link system that allows you to:

Generate shareable payment links
Accept payments via bank transfer or crypto
Track payment status
Handle real payment confirmations

You do not need any specific framework. Your backend just needs to make secure HTTPS requests.

Afriex vs Your Application

Afriex provides the payment infrastructure.

You build the product layer.

Responsibility	Who
Virtual accounts, crypto wallets, settlement rails	Afriex
Payment link (URL), amount, expiry, status tracking	Your App
Confirming payments securely	Afriex Webhooks

System Architecture

Client → Backend → Afriex API → Payment Rails

Your backend stores payment requests
Afriex handles payment execution
Your frontend displays payment instructions

Prerequisites

Before starting, you need:

An Afriex account
Your API key
A customerId (Afriex identifier for the recipient)

Every payment instruction you generate should be tied to a customerId.

Authentication

All Afriex API calls are made server-side.

GET {BASE_URL}/... HTTP/1.1
x-api-key: YOUR_AFRIEX_API_KEY
Content-Type: application/json

Example:

curl -sS -G "{BASE_URL}/api/v1/payment-method/virtual-account" \
  -H "x-api-key: YOUR_AFRIEX_API_KEY" \
  --data-urlencode "currency=NGN" \
  --data-urlencode "amount=5000" \
  --data-urlencode "customerId=PAYEE_CUSTOMER_ID"

Step 1: Create a Payment Link (Your Backend)

Afriex does not create “payment links” for you — you implement this.

Store:

amount
currency
description
expiry
customerId
unique token

import crypto from "crypto";

const linkId = crypto.randomBytes(16).toString("hex");

await db.payment.create({
  linkId,
  amount: 5000,
  currency: "NGN",
  customerId,
  expiresAt: new Date(Date.now() + 30 * 60 * 1000),
});

Then generate:

https://yourapp.com/pay/{linkId}

Step 2: Generate Payment Instructions

When a user opens the link:

Load the payment request
Call Afriex
Return instructions

🇳🇬 Virtual Account (Bank Transfer)

curl -sS -G "{BASE_URL}/api/v1/payment-method/virtual-account" \
  -H "x-api-key: YOUR_AFRIEX_API_KEY" \
  --data-urlencode "currency=NGN" \
  --data-urlencode "amount=5000" \
  --data-urlencode "customerId=PAYEE_CUSTOMER_ID"

Display:

Account number
Account name
Bank name

Crypto Wallet (USDC / USDT)

curl -sS -G "{BASE_URL}/api/v1/payment-method/crypto-wallet" \
  -H "x-api-key: YOUR_AFRIEX_API_KEY" \
  --data-urlencode "asset=USDC" \
  --data-urlencode "customerId=PAYEE_CUSTOMER_ID"

Response:

{
  "data": [
    {
      "address": "0x...",
      "network": "ethereum"
    }
  ]
}

If USDC is unavailable, fallback to USDT.

Step 3: Choosing Payment Method

In your backend:

If currency = NGN → virtual account
If currency = USD → crypto wallet

This logic is controlled by your application, not Afriex.

Step 4: Confirm Payment (Production)

Do NOT rely on:

Button clicks
User confirmation

Use Afriex webhooks:

Receive event
Verify signature
Match to payment record
Mark as paid

Always handle this idempotently.

Security Checklist

Keep API keys server-side only
Use HTTPS
Use unguessable link tokens
Expire links
Verify webhooks

Why This Pattern Matters

This is the same pattern used by:

Stripe
Paystack
Flutterwave

Payment links are one of the fastest ways to start accepting payments globally.

Summary

To build payment links with Afriex:

Create a customer → get customerId
Store a payment request in your database
Generate a shareable link
Fetch payment instructions via Afriex
Confirm payments via webhooks

Next Steps

Add webhook automation
Support more currencies
Build dashboards
Add notifications

Final Note

Afriex gives you the rails.

You build the product.