How to optimise authorisation rates in Singapore (2026)

Key takeaways:

• Optimising authorisation rates is the cleanest revenue lever most Singapore merchants ignore. At S$10M in annual card volume, a 1% lift is roughly S$100,000 in recovered revenue — without acquiring a single new customer.

• Most declines you are losing money on are recoverable. They come from issuer-side fraud rules, outdated credentials, or poorly formatted authorisation messages.

• Airwallex Optimize 360 applies real-time machine learning across routing, retries, network tokenisation, and ISO 8583 message formatting — embedded in the acquiring stack, not bolted on through a third-party orchestrator.

To optimise authorisation rates, Singapore businesses need to pay closer attention to what happens in the milliseconds between a customer clicking “pay” and a transaction being approved.

Many failed transactions are not true lost sales, but recoverable declines caused by issuer fraud rules, outdated card details, or avoidable technical issues in the payment flow.

This guide explains what affects authorisation rates, where merchants commonly lose revenue, and how to improve approval rates in 2026.

What is authorisation rate, and what counts as "good" in Singapore?

Before you optimise anything, you need a baseline. This section covers how authorisation rate is calculated, where Singapore merchants typically sit by segment, and how authorisation rate differs from related metrics people often confuse it with.

How authorisation rate is calculated

Authorisation rate is the share of card payment attempts that are approved by the issuing bank.

Here's the formula: Authorisation rate = (Approved transactions / Total transaction attempts) × 100

Two things matter when you measure it:

• First-attempt vs final-attempt rate. First-attempt rate measures how many payments succeed on the initial submission to the issuer. Final-attempt rate measures how many succeed after any retries. Track both — the gap between them tells you how much revenue your retry logic is recovering.

• Segment, do not average. A single blended authorisation rate hides where the real declines are happening. Best practice is to track by issuer country, BIN, card scheme, acquirer, and transaction type (one-off vs recurring, customer-initiated vs merchant-initiated). The fixes are different for each.

Healthy benchmarks (and what counts as "good")

A "good" authorisation rate depends on what you are processing.

Domestic payments perform best because the issuer recognises the merchant, the acquirer, and the card all sit in the same country. Cross-border payments — where the card is issued in a different country to your business — face stricter issuer fraud rules and consistently land lower.

Here are some benchmarks:

The information in this table has been reviewed to be accurate as of 18 May 2026.

Here’s the good news: if your authorisation rate falls below the typical band for any segment, it is almost always recoverable.

On domestic Singapore traffic, a rate below the band usually points to a configuration issue: fraud filters set too tight, a mismatched merchant category code, an unclear billing descriptor, or poorly tuned retry logic. On cross-border traffic, it usually points to a routing or local acquiring problem.

Authorisation rate vs approval rate vs conversion rate

These three metrics are often used interchangeably, but they measure different things and the distinction matters for reporting:

• Authorisation rate (also called approval rate) measures the percentage of submitted card transactions that the issuer approves. The terms are used as synonyms across the industry.

• Checkout conversion rate measures how many shoppers who reached the payment step actually completed a purchase. It includes everyone who abandoned before submitting payment — a much larger funnel that authorisation rate sits inside.

• Payment success rate is an end-to-end metric that combines authorisation rate with checkout completion. It captures both the customer-side drop-off and the issuer-side decline.

When you are diagnosing low revenue from payments, separate the two layers.

If checkout is converting well but transactions are failing at the issuer, you have an authorisation problem. If shoppers are abandoning before they submit, you have a checkout problem. This guide focuses on the first.

Why payment authorisations fail

Most merchants treat a declined payment as a customer problem. In practice, the majority of declines are decisions made by the issuing bank based on signals you control.

Soft declines vs hard declines

Every decline falls into one of two categories. Treating them the same is the most common mistake we see in payment ops.

• Soft declines are temporary. The issuer is saying "not right now" — insufficient funds, an unavailable network, a flagged transaction, or a generic "do not honor". These are recoverable. Retrying with better timing, cleaner data, or a different acquirer often succeeds.

• Hard declines are permanent. The issuer is saying "never" — the card is reported lost, stolen, closed, or the account number is invalid. Retrying a hard decline does nothing useful. Worse, it signals risk to the issuer and lowers your trust score for future transactions on the same BIN.

The single most important habit in authorisation rate optimisation is separating these two categories at the point of failure and applying different logic to each.

Decline code categories you can act on

Card networks return a response code with every decline. The codes below drive most of the recoverable revenue:

Two things to call out:

• Many issuers default to code 05 ("do not honor") as a catch-all. Treating every 05 the same is wasteful. Some are genuine fraud rejections, some are fixable through cleaner data, and some respond well to a routed retry through a different acquirer. The lift comes from segmenting your 05 declines by issuer and BIN and treating them differently.

• Mastercard's Merchant Advice Codes (MAC) and Visa's response code enrichments carry extra information beyond the decline code itself — for example, "new account info available" (trigger account updater) or "do not retry" (stop now, even on a soft code). If your gateway exposes these signals, build retry logic around them.

Why cross-border payments have a higher chance of failing

Cross-border payments fail at higher rates than domestic ones for three reasons:

1. Geographic mismatch signals. The issuer's fraud engine looks at alignment between card country, IP address, billing address, merchant country, and currency. When these don't line up, the issuer's default reaction is to decline.

2. Lack of historical trust. Issuers learn merchant patterns over time. A Singapore merchant new to a US issuer's fraud model gets declined more often until the corridor accumulates volume.

3. Currency conversion as a risk signal. A charge in a currency different to the cardholder's home currency adds another variable to the issuer's fraud score.

The good news is that these issues are often fixable. 

By improving how transactions are routed and how payment data is presented to issuers, merchants can reduce unnecessary declines and recover more successful payments. Read on to learn how to do this.

Lever 1: BIN-level smart routing

Routing decides which acquirer and which payment path your transaction takes. Most merchants think about routing at the acquirer level. The lift comes from routing at the BIN level.

Why issuer-specific routing matters more than acquirer "best path"

A typical multi-acquirer setup routes transactions to whichever acquirer has the best overall authorisation rate or the lowest cost. That logic ignores the fact that authorisation rates vary significantly by issuer-acquirer pair.

Consider a Singapore merchant using two acquirers:

• UOB-issued Visa through Acquirer A: 94% approval

• UOB-issued Visa through Acquirer B: 82% approval

• DBS-issued Mastercard through Acquirer A: 79% approval

• DBS-issued Mastercard through Acquirer B: 91% approval

A "send everything to Acquirer A" rule wins on UOB-Visa but loses meaningful revenue on DBS-Mastercard. Issuer-specific routing — also called BIN-level routing — picks the path with the highest probability of approval for that specific card range. The decision is made in milliseconds before the authorisation request is sent.

This requires enough volume per BIN-acquirer pair to build statistical confidence, a real-time decisioning layer that can change paths transaction by transaction, and direct relationships with multiple acquirers in each geography you process in.

Local vs cross-border acquiring for SG-issued cards

When a Singapore merchant processes a US-issued card through a Singapore acquirer, the transaction is treated as cross-border by the US issuer. Fraud rules tighten, interchange rises, and declines climb.

If the same transaction is processed through a US acquirer, it looks domestic to the US issuer. Across the industry, moving from cross-border to local acquiring typically lifts well-optimised cross-border authorisation rates from the 85–90% band into the 90–93% band¹.

For Singapore businesses, this means your routing strategy is about making each transaction look domestic to the issuer of the card you are charging.

Airwallex operates local acquiring in 35+ markets, so a US-issued card routes through a US acquirer and a Japanese-issued card through a Japanese acquirer, without you managing the acquirer relationships.

How machine learning chooses the path per transaction

Static routing rules break down as issuer behaviour shifts, BIN ranges change, or new acquirers join the stack. Maintaining them manually does not scale.

For every transaction, the model considers the issuer BIN and its recent approval rate on each available acquirer, the card scheme and product type, the transaction context (amount, currency, MCC, time of day), and the cost-performance trade-off across paths. It routes down the path with the highest expected approval rate.

Airwallex Optimize 360 runs this decisioning inside Airwallex's acquiring stack — not as a separate orchestration layer — so routing decisions, authorisation requests, and acquirer connections share the same data. Models retrain continuously on live outcomes, so the logic adapts as issuer behaviour changes.

Lever 2: Network tokenisation done properly

A network token replaces the card's 16-digit primary account number (PAN) with a credential issued by the card scheme — Visa, Mastercard, American Express, or Discover. If used properly, it can lift authorisation rates and reduce involuntary churn on recurring billing.

How network tokens lift authorisation rates

Two things happen when you use a network token instead of a raw PAN.

First, the credential stays valid when the card changes. If a customer's card is lost, stolen, expired, or reissued, the network updates the token automatically. The next charge against the token still goes through. The customer doesn't have to do anything.

Second, the issuer trusts the token more than a raw PAN. Network tokens are provisioned by the scheme with extra verification at setup, and the issuer knows this. Higher trust at the issuer means a higher first-attempt approval rate.

Across the same card cohort, network tokens can lift acceptance rates by up to 15 percentage points versus raw PAN¹. What you actually see depends on your card mix and issuer mix.

When raw PAN outperforms network tokens

Most articles stop at "enable network tokens". That isn't always the right call.

Some issuers — particularly smaller US banks and older legacy card programmes — still approve raw PAN transactions at a higher rate than network tokens. Their fraud models were trained on PAN data, or their internal routing handles tokens less well. If you tokenise everything, you win on the issuers that prefer tokens and lose on the ones that don't.

The better solution is to decide per issuer, per transaction. For example, Airwallex Optimize 360 picks the credential format per transaction — network token, merchant token, or raw PAN. The choice depends on which format the issuer has been approving more recently.

Network tokens for recurring billing and card-on-file

Network tokens matter most for recurring billing — B2B SaaS subscriptions, travel rebooking, marketplace payouts, usage-based invoices.

Without tokens, every card reissuance breaks a renewal. The card on file is out of date, the next charge fails with response code 54 (expired card) or 14 (invalid card number), and the subscription falls into dunning or churns.

With tokens, the credential updates at the network level before the renewal runs. The charge succeeds, the subscription continues, and the customer never sees a "payment failed" email. Pair tokens with an account updater for the cases the token can't cover — closed accounts, fraud reissuance with a new account number.

Lever 3: Intelligent retry logic

When a payment fails, the natural next step is to retry it. But when do you retry it, how often do you retry it, and through which path do you retry it?

Retry by decline code, not by clock

The default retry pattern in most billing systems is fixed-interval — try again in 24 hours, then 48, then 72. That schedule ignores everything the issuer told you with the decline code.

A code 51 (insufficient funds) is unlikely to succeed at the same time the next day. It's more likely to succeed right after the customer's payday. A code 91 (issuer unavailable) often clears within minutes. A code 14 (invalid card number) will never clear no matter how many times you retry.

Retry logic that uses the decline code does three things differently:

• Picks the right time window. Insufficient-funds retries get aligned to typical pay cycles. Issuer-downtime retries happen within minutes. Soft "do not honor" retries are spaced to let the issuer's velocity counters reset.

• Skips retries that will never succeed. Hard declines stop after the first attempt.

• Stops earlier when the signal is clear. Mastercard Merchant Advice Codes and Visa response enrichments sometimes tell you explicitly "do not retry". Honour those signals — they're how the issuer tells you the cardholder has actively asked the bank to stop the charge.

How to avoid issuer "blacklisting" through over-retrying

Issuers track how often a merchant retries declined transactions. Retry too aggressively on the same BIN and you trigger a velocity rule on the issuer's side. Once that happens, your approval rate on that issuer drops across all transactions — not just the retries.

These three rules keep you below the threshold:

1. Cap the number of attempts per card per day. Three is a typical ceiling for soft declines.

2. Don't retry a hard decline. Ever.

3. If multiple consecutive retries fail on the same BIN, pause the BIN for a window rather than continuing to push.

Routing-aware retries

A retry through the same acquirer that just failed often fails again — the issuer remembers the first attempt. A retry through a different acquirer, with different processing characteristics, can succeed.

This only works if your retry logic and your routing logic share the same data. The retry needs to know which acquirer the first attempt went through, which other acquirers have approved this BIN recently, and which path is most likely to succeed on the second attempt.

Airwallex Optimize 360 handles retries inside the same engine that handles routing. When a transaction fails, the next attempt evaluates all available paths — not just the one that just declined — and picks the one with the highest probability of approval given the decline code, the issuer, and the time elapsed.

Account updater and credential lifecycle

Not every failed renewal needs a retry. Some need a fresh credential.

When a card is closed and reissued, the new account number lives at the network before your next charge runs. An account updater service queries Visa Account Updater or Mastercard Automatic Billing Updater, gets the new card details, and updates your records before the renewal hits the issuer. The retry then runs against a valid card instead of a dead one.

Account updater handles the cases network tokens don't — closed accounts, fraud reissuance with a new account number, scheme migrations. The two work together: network tokens cover the everyday refresh, account updater covers the harder edge cases.

Lever 4: ISO 8583 message formatting and issuer trust signals

Every card authorisation request is an ISO 8583 message — a structured packet of fields sent from your acquirer to the issuer. The fields you populate, and how you populate them, change the issuer's decision. Two transactions for the same amount on the same card can get different answers based on what's in the message.

Most merchants never touch this layer. The fixes are mechanical and often produce a meaningful improvement in authorisation rates.

The fields that matter most

Not every field in an ISO 8583 message affects authorisation. These do:

• Merchant Category Code (MCC). A four-digit code that tells the issuer what kind of business you are. If your MCC doesn't match the transaction pattern — for example, a travel MCC on a subscription renewal — the issuer's fraud model flags the mismatch and declines.

• Address Verification Service (AVS) data. The numeric part of the billing address and the postal code. Issuers in the US, UK, and Canada rely on AVS heavily. Sending no AVS data on a US-issued card reduces your approval rate. Sending wrong AVS data is worse than sending none.

• CVV2 / CVC2. The three or four-digit security code. Send it on the first attempt. Don't store it and don't resend it on retries — scheme rules prohibit both.

• CAVV and ECI indicators. Generated when a transaction passes through 3D Secure. They tell the issuer the cardholder was authenticated and carry the liability shift. If you skip them on a 3DS-eligible transaction, the issuer treats it as unauthenticated.

• MIT / CIT indicators. Flags that mark whether the customer initiated the transaction (CIT) or the merchant did (MIT — like a subscription renewal). Issuers apply different fraud rules to each. Flag a renewal as a CIT and the issuer applies stricter checks than it should.

• Billing descriptor. The merchant name and city on the cardholder's statement. A clear, recognisable descriptor reduces chargebacks and declines. Issuers downgrade approvals for merchants their fraud systems don't recognise.

Audit what your current setup sends in each of these fields, then populate what's missing and correct what's wrong.

3D Secure 2.x and SCA exemption stacking

3D Secure 2 (3DS 2.x) lets the issuer verify the cardholder is who they say they are. When it runs cleanly, approval rates go up because the issuer takes the fraud liability instead of the merchant. When you trigger it on every transaction, you add friction and lose conversion.

The answer is exemption stacking. Ask the issuer to skip 3DS authentication when one of the regulatory exemptions applies, and trigger the full challenge only when it doesn't.

Exemptions you can claim on Singapore-issued cards:

• Low-value transaction. Under EUR 30 in the EEA, with equivalent low-value thresholds in other markets.

• Transaction Risk Analysis (TRA). The acquirer's fraud rate is low enough that the issuer accepts a risk-scored exemption.

• Merchant-initiated transaction (MIT). Subscription renewals, top-ups, and other charges the customer didn't actively trigger fall outside SCA when flagged correctly.

• Recurring transaction. The first charge in a series is authenticated. Later charges of the same amount are exempt.

Note that Singapore issuers behave differently to EU issuers on exemptions. 

EU issuers are required to evaluate every exemption claim under PSD2. Singapore issuers have more discretion, so some exemption flags that work on EU cards get challenged or downgraded on Singapore-issued cards. Test the behaviour BIN by BIN before assuming the exemption applies.

Why descriptor and MCC alignment matter for Singapore merchants

Two patterns come up repeatedly for Singapore merchants:

• eCommerce merchants using a holding-company name as the descriptor. The cardholder sees an unfamiliar name on their statement and disputes the charge. The issuer's fraud system flags the merchant as low-trust. Use the brand the customer bought from, not the parent company.

• Travel merchants miscoding their MCC. A hotel aggregator coded as 4722 (travel agency) gets different fraud treatment to one coded as 7011 (lodging). The right MCC depends on what you actually sell. The wrong one creates fraud-pattern mismatches the issuer can see.

Why Singapore businesses choose Airwallex to optimise authorisation rates

You can improve some aspects of payment performance yourself — but not all of them.

Certain optimisation strategies require infrastructure that’s difficult and costly to build in-house. BIN-level routing, for example, depends on having multiple acquiring partners in each region, plus a real-time decisioning layer to determine the best path for every transaction. 

Credential format selection requires ongoing visibility into issuer behaviour. Decline-code-aware retries only work when your retry logic and routing engine are connected and learning from the same transaction data.

Building and maintaining all of that often demands more engineering investment than the uplift can justify. That’s where Airwallex Optimize 360 comes in. It brings all four optimisation levers together in a single engine, so you can improve authorisation rates without having to build the underlying system yourself.

One engine for all four levers

Routing, credential format selection, retries, and ISO 8583 message formatting all run through the same models, sharing the same data.

When a transaction is declined and retried, the next attempt already knows which acquirers are available, which has been approving the BIN, which credential format the issuer has accepted recently, and which fields in the message most need to be tuned.

Local acquiring across 35+ markets

For a Singapore merchant serving customers across APAC, the US, and Europe, the acquiring footprint is what makes cross-border traffic look domestic to the issuer.

Airwallex has direct acquiring in 35+ markets, including major APAC, US, and European corridors. A US-issued card routes through a US acquirer. A Japanese-issued card routes through a Japanese acquirer. You don't manage the acquirer contracts.

Models that retrain on your live traffic

Routing models go stale when issuer behaviour shifts — and it shifts often. Optimize 360's models retrain continuously on live transaction outcomes, so the path a transaction takes today reflects how issuers were behaving this morning, not last quarter. You don't have to maintain the rules yourself.

Cards and local payment methods on one stack

GrabPay, WeChat Pay, Alipay, and 160+ other local payment methods sit on the same Airwallex payments stack. A single integration covers credit cards and the local methods your customers expect at checkout, and the success rate reporting covers all of them in one place.

Frequently asked questions (FAQs)

What is a good authorisation rate in Singapore?

It depends on what you process. Domestic Singapore card payments should sit between 88% and 92% for one-off transactions and 85–90% for recurring ones¹. Well-optimised setups push those bands two to five percentage points higher. Cross-border traffic runs structurally lower — typically 78–86% inbound to Singapore and 72–80% outbound to the US, EU, and UK¹.

What's the difference between authorisation rate and approval rate?

They mean the same thing. Both measure the share of submitted card transactions the issuer approves. The terms are used interchangeably across the industry. The metric to separate them from is checkout conversion rate, which measures shoppers who reached the payment step and completed the purchase — a larger funnel that authorisation rate sits inside.

Why are cross-border payments declined more often than domestic ones?

Issuers apply stricter fraud rules to transactions they can't pattern-match against local behaviour. A US-issued card paying a Singapore merchant from a SEA IP address has mismatched geographic signals, no local merchant history, and a currency conversion involved. Each of those is a risk variable in the issuer's fraud score. Together, they produce a gap of roughly 5 to 18 percentage points between domestic and cross-border authorisation rates across the industry¹.

How much can network tokenisation lift authorisation rates?

It can lift authorisation rates by up to 15 percentage points on the same card cohort, depending on issuer mix¹. The lift comes from two things: network tokens auto-update when a card is lost, stolen, expired, or reissued, and issuers trust tokens more than raw PANs at the point of authorisation. The actual gain you see depends on which issuers you process — some still approve raw PAN at a higher rate than tokens, which is why per-issuer credential selection matters.

Should soft declines be retried automatically?

Yes, but not on a fixed schedule. Retry based on the decline code, not the clock. A code 51 (insufficient funds) should be retried after a delay aligned to typical pay cycles. A code 91 (issuer unavailable) often clears within minutes. Cap retries at around three attempts per card per day to avoid triggering the issuer's velocity rules — over-retrying lowers your approval rate on the issuer across all transactions, not just the retries.

How do SCA and 3DS affect authorisation rates for Singapore-issued cards?

3D Secure 2.x can lift authorisation rates when it runs cleanly, because the issuer takes the fraud liability. The lift only happens if you use exemptions correctly. Singapore issuers have more discretion on exemption claims than EU issuers under PSD2, so some exemption flags that work cleanly on EU cards get challenged or downgraded on Singapore-issued cards. Test exemption behaviour BIN by BIN rather than applying a single 3DS policy across all traffic.

Sources:

1.  https://solidgate.com/blog/authorization-rate-optimization

This publication does not constitute legal, tax, or professional advice from Airwallex, nor does it substitute seeking such advice, and makes no express or implied representations / warranties / guarantees regarding content accuracy, completeness, or currency. If you would like to request an update, feel free to contact us at [[email protected]]. Airwallex (Singapore) Pte. Ltd. (201626561Z) is licensed as a Major Payment Institution and regulated by the Monetary Authority of Singapore.