Changelog

2026-10-28

Every Merchant API error body now has request_id, the same value as the x-request-id header. validation_failed errors also list every failed field in issues. Malformed JSON, an unknown path, and other framework errors now return the same JSON error envelope.
Payout create refuses a Payout that the available balance cannot cover with 422 insufficient_available_balance. Before, the Payout was created and then failed. This refusal is not stored for the Idempotency-Key, so a retry with the same key after a top-up checks the balance again.
invalid_currency and invalid_country are now currency_not_enabled and country_not_enabled, with status 422. No Merchant received the old codes in Live.
When the Provider does not accept the platform credential, Payment create returns payment_configuration_unavailable, not payment_method_invalid. The status (422), reason and payment_intent_id do not change. This is not a payer error.
approval_required and approval_not_required are reserved. The errors reference now also lists quota_exceeded, which the API already sent.
Some error messages have new wording. Switch on code, not on message. Merchant API v1 does not send them.
A 503 response now has a Retry-After header.

Direct Payment creation and Hosted Checkout creation are now separate resources. Payment intents require a complete payment method before routing; POST /checkouts accepts the minimum Payment facts and returns a signed payer URL without contacting a Provider.
The Merchant API no longer accepts or returns checkout_mode. The selected endpoint determines presentation ownership and route eligibility.

Payment and Payout Provider-truth recovery now runs independently of an active request, while hosted checkout and late Provider callbacks project the resulting status safely.
M1Pay boost_dnqr and Touch 'n Go payments can now return inline base64 QR images; hosted checkout displays them and refreshes the payment state automatically after scanning.
Test Environment workflow releases on the production target now bind each application-only Operator rollout to immutable reviewed artefacts before checking the exact registered status handlers.

Hosted payment creation keeps the signed checkout link available while processing continues, rather than returning an actionless processing intent.

Internal P2P and provider bank-transfer routes now use the canonical BANK_TRANSFER Merchant payment method. LinkDeepCode continues to use its own provider-specific route.
Merchant payment creation and hosted checkout now collect payer bank-account details only when the selected route requires them.

Direct Payment intents accept Provider-neutral payment methods and return a closed next_action; Hosted Checkout collects the payment method separately and returns checkout_url.
Organisation operators can create Test Environment Merchant top-ups, complete routed Test payment and payout intents, replay Merchant webhooks, and manage Merchant webhook endpoints from the dashboard.
Two-factor authentication enrolment reports verification errors and refreshes the authenticated session after setup.

LinkDeepCode P2P bank-transfer deposits open through a hosted payment page, keeping provider payment URLs and bank details out of Merchant API responses.

Merchants can add settlement bank accounts and configure automatic settlement thresholds, targets, and allocation splits from the dashboard.
Organisation operators can manage integration access, policy rules, pricing, limits, reserves, and settlement controls in one consolidated team view.
Platform-managed integrations now keep provider costs and wholesale Operator pricing separate, while Operators retain control of downstream Merchant pricing.
Settlement and policy money fields now accept currency-aware decimal amounts and validate them consistently before saving.

Dashboard date ranges now include every transaction in the selected organisation-local calendar days.
Dashboard payout and net-flow totals include committed payouts that are still processing.
Analytics reports now distinguish failed, delayed, refreshing, and unbuilt reporting projections.

Payment intent examples use the public FPX method code and include the required customer object.
Payout cancellation examples show the immediate 202 response before the asynchronous terminal cancellation state.
Webhook documentation lists the signed events Merchants can receive without advertising a webhook-management endpoint.

New entries land here the moment a public change ships.