Skip to main content

​
Collect a payment

The normal payment flow is: create a customer, create a payment request, send the payer to the returned checkout link, then confirm the final status from your server.

​
1. Preview the exchange rate

Use the quote endpoint when you need to display the source amount before checkout. amount is the amount you want to receive in targetCurrency; sourceCurrency is the payer’s currency.
The exchange-rate response is useful for display. Create the payment promptly after quoting so the payer sees a current amount.

​
2. Create a payment request

reference must be unique for your organization. Generate it on your server and persist it with your order or invoice so retries never accidentally create a second payment.

​
Choose which payment methods to offer

Before creating the request, retrieve the methods available for the payer’s source currency:
Pass one or more returned IDs in paymentMethods. The hosted checkout displays only those methods. If you omit paymentMethods, the request keeps the default provider behavior for backward compatibility. When OPay is enabled, pass "provider": "opay" with "sourceCurrency": "NGN" to collect through OPay. Offer bank_transfer, or card where direct card payments are enabled. Share the returned paymentLink. Inflow shows the temporary bank account or collects card details and opens the bank’s 3-D Secure challenge if required.
An empty array, an unknown method, or a method that is unsupported for the source currency or selected provider is rejected before the payment request is created.
The response includes a payment ID for reconciliation and a payer-facing link. Use paymentLink when it is present; it is the normalized hosted checkout URL across supported providers.
Depending on the configured payment provider, the response can also contain a linkToken for a client-side authorization integration or a checkoutUrl. Do not assume every provider returns the same provider-specific field; use the payer-facing paymentLink when available.

​
3. Send the payer to checkout

Redirect the payer in the same browser tab, or present the link in an in-app browser on mobile. Keep the payment creation request on your server so your API key remains private.
The redirectUrl returns the payer to your application after authorization. Treat that redirect as a user-experience signal—not as proof that the payment settled.

​
4. Verify the payment server-side

Look up the payment with its Inflow ID before fulfilling an order. This endpoint refreshes live payments from the provider where applicable.
Fulfil only after the status your business requires—typically executed (when provider confirms receipt of funds) or settled (when funds clear into your wallet). Note that automated payouts or withdrawals can only be triggered once the payment is settled. Handle failed, cancelled, and expired by letting the customer try again with a new payment request. If an eligible pending payment’s link expires, request a replacement rather than creating a duplicate reference:
Only payments in created or pending state can be refreshed or cancelled. See the payment API reference for every request field and provider response.