Build payment infrastructure that authorises more and loses less.

Every 1% improvement in payment authorisation rate is 1% more revenue from the customers you already have.

Payment failures are silent revenue losses. A card declined by an issuer for "insufficient funds" that is actually a false positive from a fraud model costs you a customer who wanted to pay. A payment flow without 3DS2 in the EU results in PSD2 non-compliance. A checkout without Apple Pay loses mobile users who will not type their card number on a phone. A reconciliation system that runs manually every month catches discrepancies 30 days late. PROPELOO builds payment infrastructure where every component — gateway selection, checkout UX, decline recovery, reconciliation — is engineered to maximise authorisation rate and minimise revenue leakage.

The full payment engineering stack.

Payment infrastructure has six engineering domains, each contributing to authorisation rate and operational reliability.

System Layers

• Payment Method Layer: Card, UPI, wallets (Apple Pay/Google Pay), BNPL, bank transfer, crypto — method selection and checkout optimisation
• Gateway Integration Layer: PSP SDK integration, 3DS2, tokenisation, saved payment methods, webhook handling
• Decline Recovery Layer: Smart retry logic, alternative PSP routing, updater services, dunning for subscriptions
• Reconciliation Layer: Settlement file processing, transaction matching, dispute management, payout tracking
• Compliance Layer: PCI DSS scope reduction, PSD2/SCA, regional payment regulations

Core Technical Capabilities

• Conversion-optimised Checkout

  Payment form with Stripe Elements / Razorpay Checkout for PCI scope reduction, Apple Pay and Google Pay with one-tap checkout, saved payment methods for returning customers, real-time card validation and smart error messages that help users fix card entry errors.

• Multi-Gateway Architecture

  Primary + fallback PSP routing — if Stripe rejects a transaction, route to Braintree. Intelligent routing by card type, geography and issuer — some issuers have higher authorisation rates with specific acquirers. Automatic failover on gateway downtime.

• 3DS2 & SCA

  PSD2-compliant 3DS2 implementation with risk-based challenge exemptions — only challenge transactions above risk threshold, reducing friction for low-risk payments. Correct 3DS2 exemption flags to maximise frictionless flow rates.

• Subscription Billing

  Stripe Billing or custom subscription engine — plan management, free trials, proration on plan change, dunning sequences for failed payments (retry schedule, email notifications, final cancellation) and revenue recognition.

• Automated Reconciliation

  Automated processing of PSP settlement files, matching transactions to internal order records, identifying discrepancies (missing settlements, duplicate charges, disputed transactions) and generating reconciliation reports for finance.

• Dispute & Chargeback Management

  Automated dispute response with evidence package (order details, shipping confirmation, customer communication), chargeback rate monitoring by payment method and issuer, and dispute prevention via Visa/Mastercard pre-dispute programmes.

How we think about payment engineering.

Payment authorisation rate is a product metric, not a DevOps metric. It is owned by engineering and directly affects revenue.

• Authorisation rate is engineerable

  A 94% authorisation rate is not fate — it is the result of specific decisions: which PSP is used, how 3DS2 is implemented, whether Network Tokenisation is enabled, how payment form UX reduces card entry errors, whether decline codes are correctly handled. Each percentage point of authorisation rate improvement is revenue. Instrument your payment funnel: authorisation rate by card type, issuer, geography and payment method. Optimise the worst-performing segments first.

  Axiom:

• Every payment method reduces checkout friction for someone

  A mobile user in India who wants to pay with UPI will not enter a card number. A UK user who shops on their iPhone expects to pay with Face ID via Apple Pay in two taps. A B2B buyer needs to pay via bank transfer. Supporting additional payment methods has a cost (integration complexity) and a benefit (conversion for the users who prefer that method). The ROI calculation is: what percentage of your checkout abandonments are from users who could not find their preferred payment method?

  Axiom:

• Webhook reliability is payment reliability

  Payment events arrive via webhooks — payment succeeded, payment failed, dispute opened, refund processed. A webhook handler that crashes silently means your order management system thinks a payment is pending when it was authorised hours ago. Webhook handlers must be idempotent (the same event processed twice produces the same result), must acknowledge quickly (return 200 before processing), and must have a dead letter queue for failed processing.

  Axiom:

• PCI DSS scope reduction saves compliance cost

  If your servers ever see raw card numbers, you are in PCI DSS scope — requiring annual audits costing $50K-$300K. Using hosted payment fields (Stripe Elements, Braintree's hosted fields) means card data flows directly from the user's browser to the PSP — your servers never see it. This reduces PCI scope from SAQ D (most restrictive) to SAQ A (minimal requirements). This is an engineering architecture decision with a direct compliance cost consequence.

  Axiom:

The payment infrastructure decisions that define authorisation rate.

Each choice has a direct impact on how much revenue reaches your bank account.

• Primary PSP selection?

  Impact: Stripe for global consumer products and developer-first teams. Razorpay for India-primary products. Adyen for high-volume merchants (>$1M/month) where custom acquiring fees provide meaningful savings. Use multiple PSPs for routing and fallback.

  • Stripe — best developer experience, global coverage, 2.9% + 30¢
  • Razorpay — India-focused, UPI/netbanking, 2% fee, INR settlement
  • Adyen — institutional, volume pricing, custom acquiring at scale
  • Braintree (PayPal) — PayPal network access, good for US/EU

• 3DS2 strategy?

  Impact: Risk-based 3DS2 with correct exemption flags (transaction risk analysis exemption, low-value exemption) maximises frictionless flow rate while maintaining PSD2 compliance. Stripe Radar handles this automatically for Stripe integrations.

  • Always challenge (all 3DS transactions) — maximum protection, maximum friction, lower conversion
  • Risk-based with exemption flags — challenge only above risk threshold, maximum frictionless rate
  • Skip 3DS2 — not compliant in EU for PSD2, significant liability shift implications
  • Outsource to PSP 3DS — Stripe Radar handles challenge/exempt decisions automatically

• Network Tokenisation?

  Impact: Network Tokenisation is the single highest-impact authorisation rate improvement available. Tokenised cards are updated automatically when physical cards are reissued (new expiry, lost card replacement) — eliminating "your card has expired" declines entirely. Stripe, Adyen and Braintree all support it.

  • Enable Network Tokenisation (Visa Token Service, Mastercard MDES) — higher auth rate, cards stay valid after expiry
  • Standard card storage — simpler, lower authorisation rate, cards expire/invalidate
  • No stored cards — highest PCI simplicity, poor repeat purchase UX

• Subscription dunning strategy?

  Impact: Stripe Smart Retries recovers 15-30% of failed subscription payments automatically using ML to find optimal retry timing per card and issuer. For custom billing systems, implement: immediate retry → 3 days → 7 days → 14 days, with customer email at each stage.

  • Immediate cancellation on first failure — minimal recovery, acceptable for low-value subscriptions
  • Smart retry (3 attempts over 7 days) — recovers temporary failures
  • Extended dunning (21-day sequence with customer communication) — maximum recovery
  • Stripe Smart Retries — ML-based retry timing, Stripe handles scheduling

• Reconciliation approach?

  Impact: Automated daily reconciliation that processes PSP settlement files, matches to internal transaction records and flags discrepancies is the minimum for any business processing >$50K/month. A discrepancy undetected for 30 days is significantly more expensive to investigate and resolve.

  • Manual monthly reconciliation — simplest, 30-day error detection delay, finance team bottleneck
  • Automated daily reconciliation — catches discrepancies within 24 hours
  • Real-time reconciliation — immediate mismatch detection, highest engineering cost
  • PSP dashboard only — no reconciliation, relies on PSP accuracy

• Multi-currency approach?

  Impact: Multi-currency acquiring (accept EUR from EU customers, GBP from UK customers) reduces card decline rates and eliminates foreign transaction fees. Adyen and Stripe both support this. The conversion premium from dynamic currency conversion (2-3%) is often less valuable than the authorisation rate improvement from local currency processing.

  • Single currency, convert at checkout — simplest, foreign transaction fees for customers
  • Dynamic currency conversion — customer pays in home currency, you accept base currency
  • Multi-currency acquiring — accept and settle in local currency per market
  • Presentment currency + base settlement — show local price, settle in one currency

What PROPELOO builds.

• Checkout Payment Integration

  Full checkout payment implementation — PSP integration, Apple Pay/Google Pay, 3DS2, saved cards, error handling and conversion optimisation.

• Subscription Billing System

  Subscription billing with Stripe Billing or custom engine — plan management, trials, proration, dunning sequences and revenue recognition.

• Multi-PSP Payment Router

  Intelligent payment routing across multiple PSPs — primary/fallback logic, issuer-specific routing, geographic routing and real-time authorisation rate monitoring.

• Payment Reconciliation System

  Automated reconciliation against PSP settlement files — transaction matching, discrepancy detection, dispute management and finance reporting.

• India Payment Stack

  Complete India payments — UPI (Razorpay), net banking, cards, wallets (Paytm/PhonePe), EMI options, GST invoice generation and TDS management.

• B2B Payment Infrastructure

  B2B payment rails — bank transfer (ACH/SEPA), invoice-based payments, payment terms management, credit limit enforcement and automated dunning for B2B receivables.

The payment stack.

PSP SDKs, reconciliation infrastructure and compliance tooling each require specific components.

• PSPs

  Stack: Stripe, Razorpay, Adyen, Braintree, PayPal, Square

• Payment Methods

  Stack: Apple Pay (PassKit), Google Pay, UPI (Razorpay), Klarna, Afterpay, Bank transfer (ACH/SEPA)

• Fraud & Security

  Stack: Stripe Radar, Kount, Signifyd, 3DS2 (EMVCo), PCI DSS tokenisation

• Reconciliation

  Stack: Custom reconciliation engine, Stripe sigma, Modern Treasury, dbt (data transformation), Looker/Metabase

• Subscriptions

  Stack: Stripe Billing, Chargebee, Recurly, Custom billing engine, Lago (open source)

• Infrastructure

  Stack: Node.js / Go (payment service), PostgreSQL (transaction ledger), Redis (idempotency keys), Kafka (payment events), Datadog (monitoring)

Payment security is a regulatory requirement with criminal liability.

PCI DSS, PSD2 and regional regulations define minimum security requirements for payment processing.

• PCI DSS Scope Reduction

  Use hosted payment fields (Stripe Elements, Braintree hosted fields) so card numbers flow directly from browser to PSP — your servers never handle raw PANs. This reduces PCI scope to SAQ A, the minimal self-assessment questionnaire. Never log card numbers, even partial, in application logs.

• Webhook Signature Verification

  Payment webhooks must be verified using HMAC-SHA256 before processing. Stripe, Razorpay and Adyen all provide webhook signing — verify the signature header against the request body before acting on the event. An unverified webhook endpoint can be triggered by any HTTP client.

• Idempotency for Double-charge Prevention

  Payment API calls with idempotency keys prevent double-charges from network retries. Every payment creation request must include a unique idempotency key. The PSP returns the same result for duplicate requests with the same key instead of creating a second charge.

• 3DS2 Liability Shift

  Transactions authenticated via 3DS2 have liability shifted from the merchant to the card issuer — if the customer disputes the charge as fraudulent, the issuer bears the loss, not you. Transactions processed without 3DS2 where it was available may result in merchant-liability chargebacks. Correct 3DS2 implementation is both a compliance and a financial risk management requirement.

• Fraud Detection

  Velocity rules (block cards used more than N times per hour), device fingerprinting, IP geolocation mismatches, card testing detection (micro-transactions followed by large transactions) and ML-based fraud scoring. Stripe Radar provides this automatically; for other PSPs, Kount or Signifyd are specialist fraud tools.

• Tokenisation

  Never store raw card numbers. PSP tokenisation replaces card numbers with tokens — usable only by your specific PSP account, invalid elsewhere. Network Tokenisation (Visa/Mastercard) provides device-specific tokens that are updated automatically when cards are re-issued.

From checkout to optimised payment infrastructure.

1. 01. Payment Audit

   Assess current authorisation rate, decline code analysis, checkout abandonment data and reconciliation process.

2. 02. PSP & Architecture Design

   PSP selection, multi-gateway routing strategy, payment method prioritisation and PCI scope design.

3. 03. Checkout Implementation

   Hosted payment fields, Apple Pay/Google Pay, 3DS2, saved payment methods and payment form UX.

4. 04. Webhook & Event Processing

   Idempotent webhook handlers, payment event processing, order status updates and notification triggers.

5. 05. Reconciliation

   Automated settlement file processing, transaction matching, discrepancy alerting and finance reporting.

6. 06. Decline Recovery

   Smart retry implementation, Network Tokenisation, dunning sequences for subscriptions and alternative routing.

7. 07. Monitoring & Optimisation

   Real-time authorisation rate dashboard, decline code analysis, A/B testing for checkout optimisation.

Frequently Asked Questions