🎯 Transaction data and approval rates

Why data drives approval rates

An authorization request is a message (ISO 8583 on the networks, JSON on a PSP’s API) that travels from the merchant to the issuer through the acquirer and the scheme in 300 ms to 2 s. The issuer sees neither the website nor the customer. It sees only the fields in the message, plus the card’s history. Its decision (approve, decline, or require authentication) comes from real-time scoring fed by those fields.

The master table of transaction data

Transaction data means the fields sent in the authorization message and, where applicable, in the authentication message that precedes it. For each data element a merchant can send in an e-commerce transaction, the table below gives its status, who uses it along the chain, and its concrete effect on approval rates. “Conditional” has a precise meaning here: the element is mandatory only in certain contexts, depending on the scheme, the channel, and the transaction type.

How issuers score: consistency pays

Authorization scoring is the issuer’s assessment of a transaction’s risk before it makes a decision. On the issuer side, every authorization passes through a rules engine and a scoring model. Three families of data feed them. The first is the message itself. The second is the cardholder’s history: habits, devices, and usual merchants. The third is the network risk scores provided by the schemes: Visa Advanced Authorization, a risk score from 1 to 99 attached to every authorization, and Mastercard Decision Intelligence. The merchant controls only the first family, but it shapes the other two, because rich fields improve matching against the history.

• Geographic consistency: BIN country ↔ IP ↔ billing address ↔ shipping address ↔ currency;
• Identity consistency: cardholder name ↔ name in the email address ↔ the card’s history with this merchant;
• Time consistency: plausible local time (browser time zone vs. IP), reasonable velocity (not 4 countries in 1 hour);
• Flag consistency: ECI matches the CAVV, MIT indicators match the missing CVV, and the amount matches the transaction type.

Issuer-friendly best practices

{
  "amount": { "value": 8990, "currency": "EUR" },   // cents, card currency
  "paymentMethod": {
    "type": "networkToken",                          // DPAN rather than PAN
    "number": "4895370000000000",                    // Visa network token
    "expiryMonth": "03", "expiryYear": "2028",
    "cryptogram": "AgAAAAAAAIR8CQrXcIhbQAAAAAA="     // TAVV issued by the TSP
  },
  "shopper": {
    "email": "marie.dupont@example.fr",              // long-standing email = strong signal
    "telephoneNumber": "+33612345678",
    "ipAddress": "92.184.100.23"                     // French residential IP
  },
  "billingAddress":  { "street": "12 rue de la Paix", "city": "Paris",
                       "postalCode": "75002", "country": "FR" },
  "deliveryAddress": { "street": "12 rue de la Paix", "city": "Paris",
                       "postalCode": "75002", "country": "FR" },
                                                     // shipping = billing: +score
  "browserInfo": {                                   // 3DS2 device data
    "userAgent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_5...)",
    "language": "fr-FR", "timeZoneOffset": -120,
    "screenWidth": 390, "screenHeight": 844,
    "javaEnabled": false, "colorDepth": 24
  },
  "shopperStatement": "MODETEX*DRESS PARIS",         // readable soft descriptor
  "shopperInteraction": "Ecommerce",                 // CIT (not an MIT)
  "threeDS2RequestData": { "challengeIndicator": "noPreference" }
}
// Every optional field filled in reduces the issuer's uncertainty.
// French data throughout: FR BIN + FR IP + FR addresses + EUR -> frictionless likely.

One last factor in approvals is the quality of the acquirer–issuer relationship. Large PSPs run bilateral programs with the main issuers, covering signal sharing and the calibration of decision rules. With the same traffic mix, two acquirers can show a 2- to 4-point gap in approval rates on the same issuers. That gap is measurable, and the way to verify it is a proof of concept run before signing the contract.

Smart retries: trying again without penalties

A re-presentment, or retry, means resubmitting an authorization request after an issuer decline. The schemes sort response codes into two families. Hard declines cover lost cards, stolen cards, and closed accounts, which the issuer will never approve. Temporary declines cover insufficient funds, system outages, and limits reached. Retrying a hard decline achieves nothing, incurs fees, and damages the MID’s reputation. Retrying a temporary decline at the right time recovers several points of revenue, which matters especially for subscription businesses.

• Classify every decline: hard / temporary / soft decline / technical;
• Soft decline → immediate resubmission with 3DS;
• Technical (91, timeouts) → immediate retry, multi-acquirer cascade if available;
• Temporary (51, 05) → schedule: D+1, D+3, paydays, capped at 3–4 attempts;
• Before any retry on 54/05: query the account updater and switch to a network token if possible;
• Hard (41, 43, 57, MAC 03) → stop at once, notify the customer, offer another payment method.

Measuring approval rates: auth rate vs. conversion

The term “approval rate” covers several distinct metrics that share a name but are calculated differently. Two providers each measuring their own version produce figures that can’t be compared, even on the same traffic. The most common confusion involves two of these metrics. The authorization rate reflects the issuer’s decision. Payment conversion also counts abandonment at the 3DS challenge and technical errors.

100  checkouts started
 -4   form abandonment (UX, missing payment methods)           -> 96
 -2   merchant fraud rejections (pre-authorization)            -> 94
 -6   3DS abandonment or failure (challenge not completed)     -> 88
 -7   issuer declines (05, 51, 54...)                          -> 81
 +2   recovered by retry / soft decline resubmitted with 3DS   -> 83

Gross auth rate:        ~87%   (83 approvals / 95 requests: 88 first
                                 attempts + 7 retries)
Net auth rate:          ~94%   (83 sales / 88 unique attempts reaching
                                 authorization)
Checkout conversion:     83%   (83 payments / 100 checkouts)
=> Three different figures, all called "approval rate" in a meeting.