Skip to content
All case studies

Case study 022025

Real-time Card Authorization

An in-house authorizer that approves or declines every card payment in under 50 ms, with in-line fraud scoring and a safe degraded mode.

Role
Tech lead
Team
6 engineers, 2 data scientists
Timeline
8 months
Focus
Backend, AI

42 ms

p99 authorization decision

−38%

fraud losses

−21%

false declines

Network requests hit one authorizer that runs rules and fraud scoring within a fixed latency budget, places a hold on the ledger, and falls back to stand-in mode if anything is slow.Card networks to Authorizer; Authorizer to Rules engine (evaluate); Authorizer to Risk model (score); Rules engine to Ledger (hold); Authorizer to Stand-in mode (if degraded)Card networksISO 8583 requestsAuthorizerGo · 50 ms budgetRules enginelimits · velocity · MCCRisk modelfeatures from RedisLedgerholds and postingsStand-in modecached limitsevaluatescoreholdif degraded
Network requests hit one authorizer that runs rules and fraud scoring within a fixed latency budget, places a hold on the ledger, and falls back to stand-in mode if anything is slow.

The problem

Every rule change went through the processor's ticket queue and took weeks. Fraud rules were blunt, so good customers were declined at checkout, and the vendor's outages became our outages with no fallback. The card networks give the issuer about two seconds to answer; anything slower is declined automatically.

What I owned

  • The design doc and a latency budget for every step of the decision path.
  • The Go authorizer: ISO 8583 handling, limits, holds posted to the ledger and idempotent reversals.
  • The risk-model integration with the data scientists: a Redis feature store and a month of shadow scoring.
  • Stand-in mode, load tests at 10× peak, and the cutover from the processor one card range at a time.

Key decisions

  1. 1

    A latency budget for every hop

    The whole path had to finish in 50 ms at p99. Each dependency got its own budget and timeout, and a step that runs out of time falls back to a safe default instead of holding up the answer.

  2. 2

    Degrade, never stall

    If the risk model or a store is slow, the authorizer switches to cached limits and conservative rules. Customers keep paying, and every stand-in decision is re-scored afterwards.

  3. 3

    Shadow-score before enforcing

    The fraud model scored live traffic for a month without affecting decisions. We enforced it only once its declines matched what fraud analysts would have done.

  4. 4

    Cut over by card range

    Traffic moved from the processor one BIN range at a time, starting with employee cards, with a one-line rollback to the old path.

Outcome

Every card transaction now runs through the in-house authorizer. Fraud rules ship in a day instead of weeks, good customers are declined less often, and when the risk model failed during Black Friday, stand-in mode took over and customers didn't notice.

  • Go
  • Redis
  • PostgreSQL
  • Kafka
  • Python
  • ISO 8583