We Build Payment Gateways for FinTech Companies

Most payment gateways use simple rule-based routing ("German cards → Adyen, US cards → Stripe") or round-robin, leaving 5-15% of revenue on the table from avoidable declines. Building ML routing is hard: you need enough transaction data, real-time inference (<50ms), continuous retraining, and explainable decisions. Many attempts fail due to overfitting (model memorizes training data), data quality issues, or unacceptable latency.

Cold Start Problem:

No historical data initially (can't train model without data, can't collect good data without model)

Real-Time Requirements:

Routing decision must happen <50ms (checkout can't wait)

Feature Engineering:

What signals actually predict approval? (card BIN? time of day? amount? geography?)

Model Selection:

Complex models (neural nets) overfit on small data, simple models miss patterns

Multi-PSP Coordination:

Need to integrate 3-5 PSPs, handle failover, maintain contracts

Explainability:

Merchants need to understand why AI chose specific PSP (not black box)

Cost vs Approval Tradeoff:

Highest approval PSP might have higher fees (need to balance)

Continuous Learning:

Model degrades over time as PSP performance changes (need automated retraining)

Bootstrapping:

Initial merchants have low volume (100-1,000 txns/month = insufficient training data)

Phase 1: Bootstrap with Hybrid Approach (Months 1-3)

Random Exploration:

• First 10,000 transactions randomly distributed across PSPs
• Creates unbiased training dataset
• Explores all PSP performance across transaction types
• Painful short-term (suboptimal routing) but essential for quality data

Data Collection Pipeline:

• Captured every transaction feature (card BIN, country, amount, time, merchant)
• Recorded PSP decision, response time, approval/decline, error codes
• Stored in PostgreSQL + TimescaleDB (optimized for time-series analysis)

Rule-Based Fallback:

• While collecting data, used basic rules (geographic preference)
• Better than random, worse than eventual ML

Phase 2: Train First ML Models (Months 3-6)

Feature Engineering Strategy:

• Time features: hour_of_day, day_of_week, is_weekend
• Card features: BIN (first 6 digits), card_brand, card_type
• Geographic features: customer_country, bank_country, is_cross_border
• Transaction features: amount, amount_log, amount_bin (tiny/small/medium/large)
• PSP real-time performance: approval_rate_last_1h, avg_latency_1h (SECRET SAUCE)
• One-hot encoding: Convert text categories to binary columns

Model Architecture:

• One model per PSP (Stripe model, Adyen model, Checkout model)
• Each predicts: "Will THIS PSP approve this transaction?"
• LightGBM chosen:Fast training (30 sec), fast inference (5ms), excellent for tabular data
• Alternative considered: XGBoost (slower), CatBoost (better for categoricals), TabNet (needs 10x more data)

Training Infrastructure:

• Apache Airflow: Automated daily retraining at 2 AM
• MLflow: Experiment tracking (compare model versions)
• A/B Testing: New model deployed to 10% traffic first, then 100% if better
• Validation: Required 5%+ approval lift vs baseline before production

Phase 3: Production Deployment (Months 6-9)

Inference Architecture:

• FastAPI: Real-time prediction API (<50ms SLA)
• Redis Feature Store: Pre-computed PSP performance metrics (1ms lookup)
• Load on Startup: Models loaded into memory at API start (not fetched per request)
• Fallback: If ML service down, fall back to rule-based routing

Routing Logic:

• For each transaction:
• Fetch features from Redis (5ms)
• Get predictions from all PSP models (3 models × 5ms = 15ms)
• Combine with cost data (1ms)
• Rank PSPs: (approval_prob × 0.7) + (cost_savings × 0.3)
• Return best PSP (total: <50ms)

Cost-Approval Balancing:

• Not always route to highest approval if fees are 2x higher
• Optimize for expected net revenue = (approval_prob × transaction_value) - fees
• Merchant-configurable: prefer approval vs prefer cost savings

Phase 4: Continuous Improvement (Ongoing)

Feedback Loop:

• Every transaction outcome updates training data
• Declined transactions analyzed (which PSP would have approved?)
• Model retrains daily on last 90 days of data

Model Drift Detection:

• Monitor prediction accuracy weekly
• Alert if accuracy drops >5% (indicates PSP behavior changed)
• Trigger emergency retraining if drift detected

Feature Importance Analysis:

• Discovered surprising patterns:

Hour of day = 2nd most important feature (18% importance)

• Cross-border flag more important than card brand
• Weekend transactions approve 6% less on Stripe, 2% more on Adyen

Per-Merchant Tuning:

• High-volume merchants (>10K txns/month) get custom models
• Low-volume merchants share pooled model

Spayon needed PCI-DSS Level 1 compliance (most stringent level) to process payments directly without relying entirely on third-party processors. Level 1 requires annual QSA audit, comprehensive security controls, and significant infrastructure investment. Most startups avoid this by using Stripe/Braintree, but client wanted direct processor relationships for better economics and to feed proprietary transaction data into AI routing models.

• Network Segmentation: Cardholder Data Environment (CDE) must be isolated
• Encryption Requirements: End-to-end encryption, key rotation, HSM usage
• Access Controls: Multi-factor authentication, least privilege, audit logging
• Vulnerability Management: Quarterly scans, penetration testing, patch management
• Physical Security: If any on-premise infrastructure
• Documentation: 300+ pages of policies, procedures, evidence
• Annual Audit: 3-week QSA engagement costing $50K+
• Initial Architecture: Client had monolithic app storing card data (non-compliant)
• ML Data Requirements:Need transaction metadata for routing (non-sensitive) without storing card numbers

Tokenization Strategy:

• Implemented tokenization to reduce PCI scope
• Card data captured in iframe (hosted by payment processor)
• Only tokens stored in application database
• Reduced CDE to token vault and payment processing service

ML models train on non-sensitive metadata:

• card BIN (not full number), transaction amount, geography, time, approval/decline outcome

Network Architecture:

• Separate VPC for CDE (AWS)
• Jump boxes for administrative access
• No direct internet access to CDE
• WAF (Web Application Firewall) for external traffic
• ML inference API in separate, non-PCI VPC (only receives metadata)

Encryption & Key Management:

• AWS KMS for token encryption
• TLS 1.3 for data in transit
• Database encryption at rest
• Key rotation every 90 days

Access Controls:

• MFA for all administrative access
• Role-based access control (RBAC)
• Privileged access management (PAM) solution
• Session recording for audit trail

Monitoring & Logging:

• Centralized logging (ELK stack)
• SIEM for security event monitoring
• File integrity monitoring (FIM)
• Intrusion detection system (IDS)

ML model audit logs:

• Every routing decision logged with reasoning

QSA Engagement:

• Selected PCI-certified QSA
• Gap analysis before formal audit
• Remediated all findings before audit
• Passed Level 1 audit on first attempt

ML system reviewed:

• QSA verified no card data in training pipeline

Spayon needed money transmitter licenses in 48+ US states to legally process payments. Each state has different requirements, application processes, and timelines (3-18 months per state). Total cost: $500K+ in licensing fees, bonds, and legal costs. Can't process payments in a state without license.Multi-PSP architecture with AI routing added complexity (regulators questioned "who is the money transmitter?")

48+ Separate Applications: Each state has unique requirements

Surety Bonds: Required in most states ($10K-$500K per state)

Financial Statements: Audited financials required

Background Checks: Fingerprinting, criminal background for owners/officers

Business Plans: Detailed business plan per state

Compliance Programs: AML program, privacy policy, security policies

Application Fees: $5K-$100K per state (non-refundable)

Timeline: 6-18 months per state for approval

Ongoing Compliance: Annual renewals, quarterly reports, examinations

Catch-22: Can't operate without license, but states want to see existing operations

Multi-PSP Complexity: Regulators asked: "Are you transmitting money or is the PSP? Who holds customer funds?"

Phased Approach:

• Phase 1: Applied in 10 high-priority states (CA, NY, TX, FL, IL, PA, OH, etc.)
• Phase 2: Applied in 20 medium-priority states
• Phase 3: Applied in remaining states

State Licensing Consultants:

• Hired specialized law firm (FinTech licensing experts)
• Used their templates and processes
• Leveraged relationships with state regulators

Explained AI routing architecture:

• Platform routes to licensed PSPs (not transmitting directly)

Bond Program:

• Established surety bond program with insurance provider
• Blanket bond covering multiple states (cost savings)
• Financial strength demonstration (balance sheet, investors)

Compliance Program:

• Developed comprehensive AML/BSA program
• Created policies and procedures manual
• Appointed Chief Compliance Officer
• Implemented transaction monitoring system

AI routing transparency:

• Documented decision-making process for regulators

Application Optimization:

• Created "master application" document
• Customized per state requirements
• Parallel processing (submitted multiple states simultaneously)
• Responded quickly to regulator questions

Clarified business model:

• Payment facilitator routing to licensed processors

Temporary Solution:

• Operated through payment processor (licensed) while applications pending
• Collected AI training data even during temporary solution phase
• Gradually transitioned merchants to direct processing as licenses approved

Payment gateways face constant fraud attempts (stolen cards, account takeover, friendly fraud). Blocking fraud is essential, but blocking legitimate transactions loses revenue and frustrates customers. Industry average: 1-3% false positive rate means $1-3M in lost revenue per $100M processed. Challenge: Integrate fraud detection with AI routing (fraud score should influence PSP selection, but can't slow down <50ms routing decision).

Card Testing: Fraudsters test stolen cards with small transactions

Friendly Fraud: Customers claim unauthorized transaction after receiving goods

Account Takeover: Stolen credentials used for fraudulent purchases

Velocity Fraud: Multiple transactions in short time period

False Positives: Blocking legitimate high-value transactions

Customer Friction: Too many security checks = cart abandonment

Chargeback Costs: $15-100 per chargeback regardless of outcome

Processor Penalties: High fraud rates = higher fees or termination

Integration Complexity: Fraud score must feed into routing decision in real-time (<50ms total)

Cascading Risk: If high-risk transaction routed to wrong PSP, both fraud AND decline

Multi-Layer Fraud Detection:**

1.Device Fingerprinting: Track device ID, IP, browser

2.Behavioral Analysis: Mouse movements, typing speed, time on page

3.Velocity Rules: Limit transactions per card/IP/device

4.AVS/CVV Matching: Address and CVV verification

5.3D Secure: Step-up authentication for high-risk

6. Machine Learning Fraud Model:Separate from routing model (trained on fraud labels)

Risk Scoring System:

• Every transaction scored 0-100 (fraud likelihood)
• <30: Auto-approve, route normally with AI
• 30-70: Apply additional checks (3DS), route to conservative PSP
• - >70: Auto-decline or hold for manual review (don't route)

Fraud Score as Routing Feature:

• Key Innovation: Fraud score becomes input to routing models
• High fraud score (60-70) → Route to PSP with better fraud detection (Adyen)
• Low fraud score (<20) → Route based on approval probability only
• Learned patterns:"High-risk German cards approve 85% on Adyen, 65% on Stripe"

Merchant-Specific Tuning:

• Each merchant has custom risk profile
• High-risk industries (electronics, digital goods) = stricter rules
• Low-risk industries (groceries, subscriptions) = relaxed rules
• AI routing adapts per merchant risk profile

Real-Time Decision Engine:

Parallel processing:

• Fraud check + routing decision happen simultaneously
• Fraud check: <30ms
• Routing decision: <50ms
• Total: <100ms (acceptable checkout latency)
• Fallback rules if ML model unavailable

Chargeback Intelligence:

• Track chargebacks back to risk signals
• Update fraud model based on chargeback outcomes
• Identify friendly fraud patterns
• Feed chargeback data into routing model:"Avoid PSP X for transaction type Y (high chargeback rate)"

Merchant Tools:

• Fraud dashboard showing risk signals
• Manual review queue for borderline cases
• Whitelist/blacklist management
• Chargeback dispute evidence collection

AI routing insights: See which PSP chosen for high-risk transactions