Mastercard ABU is an issuer-side service where issuers proactively push card updates (new account number or expiry) to enrolled acquirers and merchants before the old credentials expire or are closed
Merchants or their PSPs must be enrolled in ABU through their acquirer; the acquirer registers the merchant's stored credential tokens or PANs with the ABU service
ABU delivers updates via a response to authorization attempts (real-time updater) or via batch file exchange depending on the acquirer's implementation
In the real-time model, when a stored card charge is declined due to an expired or replaced card, the authorization response may include updated card details that the merchant should persist and retry
In the batch model, merchants submit a file of stored PANs and receive a response file with any available updates; this is typically processed on a scheduled cadence (verify timing with your acquirer)
After receiving an update, the merchant should replace the stored PAN/expiry with the new values and reattempt the declined charge
Known gotchas
Not all Mastercard issuers participate in ABU; an absence of an update response does not guarantee the stored card is still valid
ABU update data must be stored securely and within your PCI DSS scope; receiving updated PANs in batch files requires proper handling to avoid compliance violations
Real-time ABU updates in authorization responses are network-message-level features; your acquirer's API must expose these fields — verify your acquirer surfaces them before relying on them
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp