Skip to main content
POST
Afriex SDK
Coming soon. Hosted checkout is not yet generally available in production, but you can already try it end-to-end in the sandbox/staging environment today. Use sandbox to call this endpoint, see how it works, and validate your integration while we finish the production rollout, which we expect to ship in the coming weeks.
Create a hosted checkout session for a customer. Afriex returns a checkoutUrl that you redirect the customer to so they can complete payment on Afriex’s hosted page.
Testing in sandbox? A checkout session’s underlying transaction settles automatically, usually within about 5-6 minutes, and triggers the same webhook and redirect behavior as a real payment (see How it works below). Control the outcome through merchantReference: include fail for a FAILED result, or add SIMULATE_INSTANT to settle in about 30 seconds instead of waiting. For mobile money, SIMULATE_OTP / SIMULATE_NO_OTP control whether the payment requires the OTP step shown on the hosted page. See Testing transaction outcomes in sandbox.

How it works

  1. Call this endpoint with the amount you want to collect, the customer’s details, your merchantReference, and a redirectUrl.
  2. Afriex returns a checkoutUrl.
  3. Redirect the customer to that URL.
  4. After payment, Afriex redirects the customer back to your redirectUrl and fires a CHECKOUT_SESSION.CREATED webhook to your configured callback URL.

Identifying the session

The merchantReference you supply is the end-to-end identifier. Use it to look up the session, match webhook deliveries, and reconcile any resulting transaction in your system. It must be unique per session.

Amounts are in minor units

amount is denominated in the smallest unit of the currency. For example, kobo for NGN or cents for USD. To charge ₦5,000.00, pass 500000. Minimum value is 100 (one major unit).

Choosing payment channels

channels is required and lists the deposit rails you are willing to offer the customer. Supported values are VIRTUAL_BANK_ACCOUNT, MOBILE_MONEY, and CARD; pass at least one. Treat it as a cap, not an exact list. Channels the session’s currency cannot collect on are dropped silently, so you can send the same list on every corridor and let Afriex offer the right subset. For example, ["VIRTUAL_BANK_ACCOUNT", "MOBILE_MONEY", "CARD"] becomes mobile money for a KES session and cards for a USD session, all from one integration. The response echoes what the payer will actually be shown as channels, in the order you sent them.
If none of the requested channels are supported for the currency (or the currency has no deposit channel at all), the request is rejected with 422 Unprocessable Entity.

Authorizations

x-api-key
string
header
required

Static business API key issued from the dashboard. A business can provision multiple API keys, each scoped to a configurable set of permissions (e.g. read transactions, create deposits, etc). Permissions are chosen per key at creation time in the dashboard and may be revoked by deleting the key. Requests made with a key that does not include the permission required by the target endpoint will be rejected with a 403 Forbidden response; an unrecognised, malformed or revoked key returns 401 Unauthorized. Manage your keys and their permissions under Developer → API keys in the dashboard.

Headers

x-api-version
string

API version in ISO 8601 format (e.g. 2025-12-28). Defaults to latest stable.

Body

application/json
amount
integer
required

The transaction amount in minor currency units (e.g. kobo for NGN, cents for USD). Minimum 100 (equivalent to 1 major currency unit).

Required range: x >= 100
Example:

500000

currency
string
required

Uppercase 3-letter ISO 4217 currency code (e.g. NGN, GHS). Must be a currency enabled for checkout sessions on the business.

Example:

"NGN"

merchantReference
string
required

Unique merchant-supplied reference for this session. Used end-to-end to look up the session and any resulting transaction.

Minimum string length: 1
Example:

"order-2026-05-12-001"

redirectUrl
string<uri>
required

HTTPS URL the customer is redirected to after the hosted checkout flow completes.

Example:

"https://merchant.example.com/checkout/return"

customer
object
required
channels
enum<string>[]
required

The payment channels you are willing to offer the customer, at least one. This is a cap, not an exact list: you do not need to vary it per country. Channels the currency does not support are dropped and the session is created with the rest, so the same list works for every corridor (send ["VIRTUAL_BANK_ACCOUNT", "MOBILE_MONEY", "CARD"] and a KES session offers mobile money while a USD one offers cards). The channels the customer will actually be shown come back as channels on the response. The request is rejected (422) only when none of the requested channels are supported for the currency, or when the currency supports no deposit channel at all.

Minimum array length: 1
Available options:
VIRTUAL_BANK_ACCOUNT,
MOBILE_MONEY,
CARD
metadata
object

Optional flat key/value metadata to attach to the session. Both keys and values must be strings. At most 50 entries; keys up to 128 characters, values up to 1024 characters.

Response

Checkout session created successfully.

data
object