Real-time authorisation decisioning: how issuers can decide every card payment

When a card is used, the card network sends an authorisation request to the issuer's processor, and an answer has to come back fast. Modern issuing processors let the issuer, or a service the issuer chooses, take part in that answer in real time. That turns authorisation from a fixed rulebook into a live decision.

How it works

• The processor receives the authorisation from the network.
• Before answering, it calls the issuer's endpoint with the payment details: amount, merchant, entry mode, location and whether 3D Secure authenticated it.
• The issuer's service answers approve or decline, and the processor relays it to the network.
• If the issuer's service doesn't answer in time, the processor applies a fallback, which the issuer should choose deliberately.

What to decide on

• Card controls the cardholder or issuer has set, such as blocking manually keyed payments.
• Context: where the card is being used compared with where the cardholder is.
• Authentication: whether the payment was verified, for example with 3D Secure.
• Behaviour: whether this payment fits the cardholder's pattern.

Latency is a product decision

Every millisecond spent deciding sits inside the cardholder's wait at the till or the checkout. Keep the decision path short: no slow lookups in the critical path, cached card controls, and a hard deadline after which the fallback applies. Decide in advance what that fallback is. For an anti-fraud layer, we argue it should be approve.

Where 0Fraud fits

0Fraud runs as the issuer's decision endpoint, alongside the processor the issuer already uses. The engine itself decides in a fraction of a millisecond, so almost all of the time budget is left for the network.