Known Issues

Fixed on 2026-08-12. These rejections now return 4xx responses with an explicit code. If you implemented a workaround that capped retries for 500 responses, you can remove it for these rejections. However, keeping a retry limit is always appropriate: do not retry 5xx responses other than upstream_timeout (504) indefinitely. We also added tools/check-open-error-codes.mjs: an unregistered internal code, or a registered code with no emission sites, now fails the commit-time check.

Fixed. During the fix, we found a fourth issue of the same kind: GET /v1/cards/{id} selected balance_micro, which had never appeared in any of the 127 migrations (the actual name is upstream_balance). That query supplied the entire card detail response and also guarded the transaction endpoint, so even correct transaction column names could not make the latter accessible. Card transactions now also return direction: amount is an absolute value, so a refund and a purchase look identical if you only inspect the amount.

Fixed. All three response paths (creation, list, and detail) now use one mapping function instead of three separate ternary expressions, which were the reason this kind of leakage could recur. Amounts consistently use decimal strings, with ledger_scale included alongside them.

Resolved on 2026-08-13. Originally recorded as one issue, this was actually two:

① Actual defects, 2 events, fixed: card.application.approved and card.status.updated. Their data.id contained the internal member ID, even though data.object said card_application / card. Retrieving the object by that ID inevitably returned 404. The missing version was a consequence of the same problem: we read the version from the table identified by data.id, but never reached the correct table. Both events now contain the actual object ID (application ID / card ID) and the actual version. ⚠ If your handler assumes that these two card events contain a member ID, restore the normal convention.

② Not defects, 7 events, unchanged with explanations added: member.created / member.suspended / kyc.result.updated / deposit.credited / exchange.order.executed / transfer.completed / earn.order.settled (only the flexible-interest-payment variant). Their objects either have no state machine (a deposit only has a credited state; exchanges and transfers execute atomically), or are not orders at all (the KYC object is a person; flexible Earn uses a balance pool). Inventing a version number would not make anything more reliable. The workaround above still applies to these 7 events. Please continue using it.

We also removed data.previous_status: it was always an empty string and had no producers. For the rationale, including why we do not populate it with an actual value, see the Webhook guide.

On our side, the commit-time check tools/check-webhook-route.mjs now fails when a notification call does not tell the bridge which object the notification refers to. Previously this silently fell back: the event was sent, its signature was valid, your endpoint returned 2xx, and only the subsequent retrieval returned 404.

Fixed. The upstream clients for all four product lines now apply the injection layer at the lowest-level fetch call. merchantAuth establishes its scope, requiring both a sandbox hostname and resolution to a shadow entity.

Two deliberate design choices are explained in the sandbox guide: · Only the call that moves funds is replaced. Quotes, decoding, and queries to the same provider still call the real upstream. Replacing every call would make orders fail cleanly before funds were locked, leaving the “funds may already have been released” branch—the one you actually need to test—unreachable. · The injected value is an upstream response, not an order status. We process it using exactly the same classification, retries, audit trail, and state machine as production. What you observe in the sandbox is therefore how the same situation would behave in production.

Fixed on 2026-08-13. This endpoint now returns the standard envelope { data, next_cursor, has_more } (without pagination, so next_cursor is always null and has_more always false). Your generic paginator no longer needs a separate branch.

⚠ balances has not been removed. It is still returned, and points to the same array as data. This is a transitional compatibility field: replacing it outright with data would cause existing integrations that read balances to silently receive undefined at deployment time. Rather than an explicit error, all balances would appear to disappear, and most interfaces would render them as 0.

Follow this order: new integrations must read data; existing integrations reading balances should migrate when scheduled. The removal of balances will be announced in advance in the changelog; there will be no second compatibility period.