API for International Payments: How Receiving Works

An API for international payments is a set of endpoints that let your software move cross-border money without a human logging into a bank portal. Instead of manual wires, your platform calls the API to open accounts, receive funds, and reconcile them in code.

For an Indian platform, the useful question is narrower than most guides admit: not “how do I send payouts abroad” but “how does my product receive cross-border money into India and settle it in INR”. That is the gap this guide fills.

In brief, an international payments API usually gives you:

• Receiving accounts in USD, GBP, EUR and other currencies your customers can pay into
• Webhooks that fire the moment money lands, so you never poll a portal
• Reconciliation data that ties each credit to an invoice or sub-account
• Settlement into an Indian bank account, typically the next business day (T+1)
• Compliance handled inside the flow: purpose codes, eFIRA and KYB

If you build a marketplace, SaaS product or aggregator, Xflow for Platforms exposes white-label receiving accounts and webhooks so your users get paid without leaving your product. The rest of this page explains how that machinery works end to end.

An international payment API turns a bank workflow into a request and response. You authenticate once, create an account object, then listen for events as money arrives.

Most cross-border payment APIs follow the same four stages:

Step 1: Authenticate

Authenticate with an API key or OAuth token over HTTPS. Each request is signed, so the provider knows the call is really yours.

Step 2: Provision a receiving account

Provision a receiving account for a customer or sub-merchant. The API returns account details (for example a USD account number and routing number, or an IBAN) that a foreign payer can send to.

Step 3: Get notified by webhook

Get notified by webhook when a credit hits that account. The event carries the amount, currency, sender reference and a purpose code.

Step 4: Settle and reconcile

Settle and reconcile: the provider converts the foreign currency and settles INR to your registered Indian bank account, with a data record you match against your ledger.

The design principle is that your code never touches the correspondent-banking plumbing. You work with clean JSON objects while the payment API for developers handles the FX conversion, banking partners and regulatory reporting underneath.

To accept international payments through an API as an Indian business, you complete business verification once, then wire the receiving flow into your product.

A realistic sequence looks like this:

Step 1: Onboard and verify (KYB)

Submit PAN, GSTIN where applicable, IEC for goods exporters, and entity documents. Know Your Business (KYB) is a one-time step, usually online in minutes.

Step 2: Get API credentials

A sandbox key to build against, then a live key once verification clears.

Step 3: Create a receiving account per customer

Create a receiving account per customer via the API and show those account details in your checkout or dashboard.

Step 4: Handle the credit webhook

Handle the credit webhook to update your own records and trigger fulfilment.

Step 5: Reconcile and settle

Map each credit to an invoice, then receive INR the next business day (T+1) into your bank account.

The foreign-currency account your customer pays into is a ring-fenced routing account issued through the banking partner, not a nostro account your business owns abroad. It exists only to book the FX and route funds to your pre-registered Indian bank account. Xflow's virtual bank account number works exactly this way: money can move only to your own Indian account, never anywhere else.

Below is a pseudo-request lifecycle for receiving a payment: create a receiving account, listen for the credit webhook, then read the settlement. Field names are illustrative; check your provider's live reference for exact schemas.

Step 1: Create a receiving account for a customer

Step 2: Receive the webhook when money lands

Step 3: Read the INR settlement

Your service verifies the webhook signature, matches sender_ref to invoice INV-2043, and marks it paid. No portal login, no manual FIRA request. For a deeper pattern on event-driven design, see how an API first payment platform structures these callbacks.

People use the terms loosely, but they solve different jobs. A gateway usually authorises card checkouts; a cross-border payment API provisions accounts, moves funds and settles across currencies programmatically.

If your job is choosing a provider rather than understanding the mechanism, that comparison lives on the international payment gateways roundup, so this guide stays focused on how the API itself works. For B2B-specific tooling, a dedicated B2B payments platform guide compares options by use case.

This is where India-inward APIs differ sharply from generic global-payout tools. Receiving foreign money into India triggers RBI reporting that a payout API simply never touches.

A compliant receiving API bakes the paperwork into the flow instead of leaving it to you:

• Purpose codes: each credit is tagged with an RBI purpose code (for example P0802 for software services), which classifies why the money came in. See the reference on RBI purpose code for inward remittance.
• eFIRA: a Foreign Inward Remittance Advice is auto-issued as proof of receipt, so GST refunds and export records stay clean.
• KYB and screening: sender and beneficiary checks run before funds settle.
• FIRC continuity: the downstream certificate workflow through your AD-1 bank is unchanged.

Xflow operates under a final Payment Aggregator - Cross Border (PA-CB) authorisation from the Reserve Bank of India (RBI) for both exports and imports, as of February 2026. Framed plainly: compliance is meant to be relief here, not a checklist you carry alone. The auto-issued eFIRA is the record most Indian exporters spend hours chasing manually.

FX cost is the number most API pages skip. Banks quote a small-looking percentage, but the real leak is the rate they convert at, not just the fee.

Banks mark up a non-public interbank rate (IBR). A transparent API marks up the live mid-market rate (MMR), the same reference rate you see on public FX sites. Here is an illustrative comparison for a $10,000 software-services receipt at an illustrative USD/INR mid-market rate of ₹95.00.

Figures are illustrative; your rate depends on the live MMR and your plan. Xflow's published pricing is a flat fee on smaller invoices, then a percentage on FX above a threshold (Starter, then 0.6%; Growth, then 0.4%; Scale custom), converted at the mid-market rate. The point is not a promised saving but that you can see the rate, which a bank card rate hides.

An international money transfer API and a receiving API sit at opposite ends of the same rail. A transfer or payout API pushes money out to beneficiaries; a receiving API pulls money in and settles it locally.

Most APIs in the market, from the big global names, are built for the send side: mass payouts, payroll, vendor disbursement. That is useful if you pay people abroad. It does little for an Indian platform whose users need to collect from foreign customers and land INR at home.

If your product needs both directions, treat them as two integrations with different compliance surfaces. The inward leg carries the RBI reporting; the outward leg carries different rules. For the receiving side, receiving accounts plus credit webhooks are the core primitives you build against.

Beyond features, the day-to-day experience decides how fast you ship and how little breaks in production. Weigh these criteria before committing.

For a marketplace, the ability to open sub-accounts per seller and monetise with your own fee model matters as much as raw uptime. That white-label and revenue-share angle is covered in the guide on how to add global payments capabilities to your platform business.