Changelog

Creating a customer requires `type` and `has_wallet`

Creating a customer has new requirements:

• type is required: individual or business.
• has_wallet is required: true or false.
• Disposable email addresses are rejected.
• Customer endpoints are available to NGN businesses only.

What you need to do

Send type and has_wallet on every create customer request, and use a real email address for each customer.

{
  "type": "individual",
  "first_name": "Ada",
  "last_name": "Okafor",
  "email": "ada@example.com",
  "phone": "+2348012345678",
  "has_wallet": false
}

API key mode must match your account

Atlas now rejects requests where the API key's mode doesn't match your account's mode:

• a test key on an account in live mode, or
• a live key on an account in test mode.

The API returns 401 with a message telling you which key to use.

What you need to do

Use test keys while your account is in test mode, and switch to live keys when it goes live. See the authentication guide.

Checkout webhooks use `event_type`

Checkout webhooks now send the event name in event_type, like every other Atlas webhook. The eventType field introduced on 22 May 2026 is no longer sent.

{
  "event_type": "CHECKOUT_COMPLETED",
  "data": { "...": "..." }
}

What you need to do

Read event_type from checkout webhooks. If you read eventType, switch to event_type.

See the webhooks guide.

Dedicated checkout webhooks

Checkout payments now send a dedicated checkout webhook, with the checkout in the payload. The pay-in webhook is no longer sent for payments made through checkout.

Checkout webhooks use these events:

• CHECKOUT_PROCESSED: the payment was received and is being processed.
• CHECKOUT_COMPLETED: the checkout was paid.
• CHECKOUT_FAILED: the payment failed or the checkout was cancelled.

On this date the event name was sent in an eventType field. It was renamed on 26 May 2026; see checkout webhooks use event_type.

What you need to do

Handle the checkout events above for checkout payments. Pay-in webhooks still arrive for inflows that are not linked to a checkout.

See the webhooks guide.

FX swap status `canceled` is now `cancelled`

FX swap responses now return cancelled for cancelled swaps, instead of canceled. Swaps also include a reason field explaining a cancellation.

What you need to do

If you compare swap status to canceled, compare to cancelled instead.

{
  "status": "cancelled",
  "reason": "<why the swap was cancelled>"
}

Checkout amount must be at least 100

The amount you send to initiate a checkout must now be at least 100. Smaller amounts fail validation.

What you need to do

Check amounts before you initiate a checkout, and don't offer checkout for totals under 100.

Checkout payments send checkout events

Pay-in webhooks for payments made through checkout now set event_type to:

• CHECKOUT_COMPLETE when the payment succeeds, or
• CHECKOUT_FAILED when it fails.

Before this change they used IN_FLOW_SUCCESS_EVENT, the same event as other inflows. Pay-ins that are not linked to a checkout still use IN_FLOW_SUCCESS_EVENT. Checkout pay-in payloads also include checkoutReference.

These events were replaced on 22 May 2026; see dedicated checkout webhooks.

What you need to do

If you matched checkout payments on IN_FLOW_SUCCESS_EVENT, also handle CHECKOUT_COMPLETE and CHECKOUT_FAILED.

`source_reference` is required for checkouts and API payouts

source_reference is now required when you:

• initiate a checkout, and
• create a bank transfer payout through the API.

Requests without it fail validation.

What you need to do

Send your own ID for the request as source_reference, and store it so you can look the record up later.

{
  "amount": 5000,
  "currency": "NGN",
  "source_reference": "order_10234"
}