ML-Assisted Authorization & Decline Handling
A clearer answer to every decline — and a safeguard the merchant approves first.
Overview
The authorization work in one minute
Revenue improvement, U.K./EU Authorization Report, one quarter
Merchants in the U.K. and EU were losing revenue to declined authorizations they couldn't diagnose or fix. This was scoped, designed and measured as its own workstream — not as part of the portal redesign.
- Role
- Senior Product Designer · design lead for the Authorization Report experience
- Team
- No direct reports. Embedded with applied-ML, merchant-facing payments, and legal & compliance partners.
- Decision authority
- I decided the interaction model and the human-control points. Model behaviour and network-rule compliance stayed with applied ML, risk and legal.
- Primary users
- U.K. and EU merchants and their operations teams, plus the developers wiring retry policy.
- Constraints
- Network rules on retries, model explainability requirements, and a merchant base that would not accept an opaque system deciding revenue.
- Market
- U.K. and EU merchants
developer.paypal.com is a public surface, but the visuals here are reconstructions and internal analytics and risk detail remain confidential. Reconstruction does not verify the outcomes shown.
Problem and stakes
A decline code is not an explanation.
Merchants saw cryptic decline codes (for example 'DO_NOT_HONOR') with no path to remediation. Authorization rate was bleeding revenue silently, and no surface in the product told an operations team what to do next.
Auto-retrying declined transactions can violate network rules and trigger fines, so an autonomous system was a non-starter for legal. Any design had to put the merchant in front of the model's actions, not behind them.
How the system works
Statistical modelling in front, a decision matrix behind.
Statistical modelling, including linear-regression-based analysis, identified patterns behind authorization declines, while a decision matrix translated those signals into safeguards and actions.
For recurring payments using expired stored cards, the system refreshed the stored credential when an updated credential was available, allowed the payment to proceed and alerted the merchant. This prevented avoidable declines from damaging authorization performance.
AI and human control
Four design decisions that made the model trustworthy.
- 01
Explain every decline in plain language
Every decline surfaces a plain-language explanation, the model's confidence in that explanation, and a ranked list of fixes (retry timing, alt-funding, AVS tweak). Merchants can click any fix to simulate the rerun.
Trade-off: required slowing down some checkout flows by 80–200ms to fetch the explanation; merchants overwhelmingly preferred the latency to the lost revenue.
- 02
Confidence display without false precision
Three-band confidence (High / Medium / Low) with a tooltip explaining what each band means and the historical accuracy of that band on the merchant's own traffic.
Trade-off: loses fine-grained ranking inside a band; gained dramatically in trust and reduced 'why did your AI say…' support tickets.
- 03
Human-in-the-loop on auto-retry rules
AI proposes retry strategies; the merchant approves a policy (per BIN, per region, per amount band) once, then the AI executes within those bounds and logs every decision for audit.
Trade-off: slower initial activation (merchants must read and accept policy), but turned a legal-blocked feature into a shippable one.
- 04
Evaluation loop merchants can see
A weekly 'AI scorecard' surface: predictions made, accepted, overridden, and the resulting auth-rate delta vs. the no-AI control group on the same merchant's traffic.
Trade-off: required running a permanent holdout cohort (slight revenue cost) — paid for itself by removing the 'is this even working?' objection in every renewal call.
- 01
Pushed the applied-ML partners to expose model confidence and a plain-language reason on every declined transaction, instead of a generic 'try again' fallback. That decision is what made the Authorization Report usable for merchants.
Shipped experience
Where the merchant meets the model.
All screens are reconstructions — no production UI or merchant data. Every image expands.
Outcomes and provenance
What changed for U.K. and EU merchants.
Revenue improvement, U.K./EU Authorization Report, one quarter
- 01
The ML-assisted Authorization Report contributed approximately $1M in measured revenue improvement across multiple U.K. and EU merchants over one quarter.
Measured by the payments team across multiple U.K. and EU merchants over a single quarter and rounded. This figure belongs to the authorization workstream only and is never combined with developer-portal results.
Reflection
The thing that made it ship.
The unlock was not the model. It was agreeing, with legal and applied ML, that the merchant approves a policy before the system acts — which converted a blocked feature into one that could be measured against its own holdout cohort.
If I ran it again I would build the scorecard first. Merchants judged the system on whether they could see it working, long before they judged it on accuracy.
The other PayPal initiative
PayPal Developer Platform
The developer portal and documentation redesign — a separate problem, users and measurement surface.
Read that case study