1. Use Case
BPN OpenAPI
  • Getting Started
    • Introduction to BPN
    • Architecture Overview
  • Onboarding & Prerequisites
    • Product Demo
    • Sandbox & Test Environment
    • Signature Authentication Mechanism
  • Use Case
    • Fiat Collection via Virtual Accounts & Local Collection Rails
    • Convert Stablecoins
    • Transfer
    • Wallet
    • Compliance (Travel Rule Information Submission)
    • RFI process
  • API Reference
    • KYB
      • Share KYB/KYC Info For Sub User
      • Get KYB Sub User Status
    • Account Management
      • Inquiry Master VA Balance
      • List Primary Virtual Accounts
      • Create Virtaul Account
      • Get Virtual Account Detail
      • List Virtual Account
      • Send Email Verify Code
      • Query bank info by account number
      • Payout via Virtual Account
      • Refund Virtual Account Order
      • Get Virtual Account Order Detail
      • List Virtual Account Orders
      • Submit Invoice
      • Get Invoice list Status
      • List Banks
      • Add Bank Account
      • List Bank Account
      • List RFI Sub Virtual Account
      • Get Sub Virtual Account RFI Template Info
      • Sub Virtual Account Submit RFI
    • Wallet
      • List Wallets
      • List Sub Account
      • Create Sub Account
      • Wallet Internal Transfer
      • Query Wallet Internal Transfer Detail
      • List Wallet Internal Transfer order
      • Get Asset Balance
      • Get Deposit Address
      • Add Deposit Sender
      • Add Withdraw Whitelist
      • Delete Withdraw Whiltelist
      • Request Withdraw
      • Query Transaction History
    • FX
      • Inquery FX Rate
    • BPN Transactions
      • Get Stablecoin Quote
      • Create Stable Order
      • Get Order (Single) Detail
      • List Orders(Batch)
    • Reconciliation
      • Get Reconciliation Order List By Page
    • Crypto Payment Link
      • Abnormal fund
        • Abnormal funds
        • Matchable Payment links
        • Link Order(Abnormal fund)
        • Submit to platform
      • Create Payment Link
      • List Payment links
      • Get Curreny Network Config
    • External Provider
      • FE: Create stablecoin collection sub-account link
      • Create stablecoin collection sub-account link
      • Get sub wallet account
      • List sub wallet accounts
      • Change sub wallet status
      • Query stablecoin collection order list
      • Query stablecoin collection order status
      • Get quote
      • Accept stablecoin collection order
      • Reject stablecoin collection order
      • Query USD balance
      • USD Payout (withdrawal)
      • Query USD Payout order status
      • Query USD Payout order list
    • Mock
      • Mock Virtual account Payin Order
      • Mock wallet deposit transaction
      • Mock Payin Order Refund
      • Mock Payout Order Update Status
    • Pay Session
      • Request Pay Session
  • Webhooks & Events
    • Resend Fail Webhook
      POST
    • Open Virtual Account Status
    • Virtual Account Payment Status
    • Virtual Account Invoice update
    • Transaction Status Notification
    • KYB Status Notification
    • Deposit Sender Detail Required
    • Abnormal Fund Notification
    • WALLET_TRANSFER_ORDER_UPDATED
    • Sub Virtual Account RFI Required
    • Sub Wallet Update
    • wallet address whitelist Copy
    • Crypto Deposit Order Notification
    • Collect Order Updated
    • Usd Payout Order Updated
    • onboard result
    • partner order status
    • PaymentLink Notification
  • Partner Flow
    • inquiry supported currency
    • KYC/KYB Sharing
    • inquiry onboard status
    • get price
    • Create order
    • order list
    • inquiry single order
    • get user deposit address
    • get payment instruction
    • sync fund notification
    • daily settlement records
  • Appendix
    • Enum
    • Virtual Account(VA) Support List & KYB requirement
  • Release Notes & Changelog
  1. Use Case

Fiat Collection via Virtual Accounts & Local Collection Rails

Use BPN's fiat collection APIs to receive local-currency payments through Virtual Accounts, local payment instructions, or pooled collection accounts.
The high-level integration lifecycle is standardized across markets, while the receiving instrument, required fields, limits, and operational rules vary by currency.
One integration model, market-specific capabilities
Integrate the common order, webhook, query, refund, and reconciliation model once. Before enabling a currency, review its supported collection instrument and market-specific requirements.

1. Standard Collection Flow#

Provision or retrieve receiving details
                ↓
Payer sends local-currency funds
                ↓
Receive PayIn webhook notification
                ↓
Query and reconcile the collection order
                ↓
Refund or use the available balance
1.
Provision or retrieve the receiving details supported by the selected market.
2.
Present the bank account, payment key, QR code, or payment link to the payer.
3.
Receive a webhook when the incoming payment is confirmed.
4.
Use the returned orderId to query and reconcile the same PayIn order.
5.
Refund the payment when eligible, or use the available fiat balance in subsequent flows.

2. Supported Markets#

🇧🇷 BRL#

Static PIX Key
Static QR Code generated with the PIX Key
Dynamic QR Code
Maximum Dynamic QR validity: 72 hours

🇲🇽 MXN#

CLABE account

🇳🇬 NGN#

Collection account

🇰🇪 KES#

Collection account

🇨🇴 COP#

Static collection account
Dynamic Payment Link

🇬🇭 GHS#

Dedicated Virtual Account
One VA is assigned to each merchant or end user

🇿🇦 ZAR#

Pool Account with an assigned reference code
Optional dedicated named account after KYB review
ZAR collection models
By default, ZAR payments are received through a Pool Account. BPN assigns a specific reference code to identify and attribute each incoming payment.
If a customer requires a ZAR account in its own legal name, it may submit the required KYB documents and apply for a dedicated named account. Once approved, the account can be used for both receiving and sending funds.
Payments that cannot be matched automatically are routed to manual review.

3. Provision Receiving Details#

Use Create Virtual Account to provision a dedicated or dynamic receiving instrument where supported. For pooled collection markets such as ZAR, use the Pool Account receiving details available to the merchant.
Receiving instruments fall into three categories:
Persistent receiving details: Static PIX Key, CLABE, collection account, or Virtual Account.
Dynamic payment instructions: Dynamic QR Code or Dynamic Payment Link with a defined validity period.
Pooled collection: Shared Pool Account with an assigned reference code for transaction attribution, currently used for ZAR.
Dedicated named account: A ZAR account opened after KYB review for customers requiring an account in their own legal name.
All account provisioning requests are processed asynchronously. Subscribe to Open Virtual Account Status to receive the final account-opening result.

4. Receive and Track Payments#

Subscribe to Virtual Account Payment Status to receive incoming payment notifications.
For PayIn orders:
A confirmed PayIn is notified as SUCCESS.
PayIn does not use PROCESSING.
Use orderId as the unique identifier for tracking the order.
Process webhook events idempotently.
Use the order query API as a fallback when verification is required.
For detailed webhook and refund status rules, see Virtual Account Webhook Status Rules.

5. Refund a PayIn#

Use Refund Virtual Account Order to request a refund for an eligible successful PayIn.
The refund is returned through the supported original-route process.
REFUNDING means the PayIn refund is being processed.
The final refund status is REFUNDED or REFUND_FAIL.
Keep the refund associated with the original PayIn order for lifecycle tracing and reconciliation.
Merchant-initiated original-route refunds are supported for both GHS and ZAR, including ZAR Pool Account and dedicated named-account collections.
System-initiated refunds may also occur when an incoming payment exceeds an applicable account or transaction limit.

6. Query Orders and Balances#

Operational Order Query#

Use List Virtual Account Orders to review and reconcile incoming payment orders.

Master VA Balance#

Use Master VA Balance Inquiry to query the merchant's fiat balance by currency.
GHS VA balances and ZAR Pool Account or dedicated named-account balances are included in the merchant's balance.
Once the collected balance is available, it may be used in supported payout, transfer, or stablecoin conversion flows. All supported collection currencies can be converted to USDC or USDT.
Convert collected fiat
To convert an available fiat balance to USDC or USDT, see Convert Stablecoins.

7. Reports and Reconciliation#

Use Get Reconciliation Order List By Pagefor periodic billing and reconciliation of incoming payments.
Merchants should reconcile:
BPN orderId and merchant-side order records.
Payment amount and currency.
PayIn and refund statuses.
Balance movements.
Operational order results and period-end reports.

8. Integration Requirements#

Use a unique request identifier when creating resources or initiating transactions.
Use orderId as the primary identifier for PayIn tracking.
Verify webhook signatures before processing events.
Process repeated webhook events idempotently.
Use active order queries when a webhook is delayed or additional verification is required.
Do not assume that account type, required fields, limits, or refund support are identical across markets.
Previous
Signature Authentication Mechanism
Next
Convert Stablecoins
Built with