Payment Gateway Integration for FD Booking: A Technical Deep Dive

Why FD Payments Are Harder Than E-Commerce Payments

If you've integrated Razorpay or Cashfree for e-commerce payments, you might assume FD payment integration is similar. It's not.

In e-commerce, you integrate one payment gateway. It handles UPI, cards, net banking — and you're done.

In FD distribution across multiple banks, each bank may mandate a different payment gateway, with different payment methods, different hash algorithms, and different callback mechanisms. Your payment infrastructure must route to the correct gateway based on which bank the customer chose for their FD.

The Multi-Gateway Reality

Here's what the payment gateway landscape looks like for a platform distributing FDs across 10+ issuers:

| Bank/NBFC | Payment Gateway | Why This Gateway | |-----------|----------------|-----------------| | IndusInd Bank | Razorpay (dedicated keys) | Bank requirement — dedicated Razorpay account | | South Indian Bank | Razorpay (dedicated keys) | Bank requirement — separate Razorpay keys | | Suryoday SFB | PayU (web) / Cashfree (SDK) | Different gateway for different channels | | Unity SFB | Cashfree | Bank's preferred gateway partner | | Utkarsh SFB | ZaakPay | Bank's designated gateway | | Shivalik SFB | ZaakPay / Cashfree | Dual gateway support | | Bajaj Finance | BFL Native PG / PayU | NBFC's own payment infrastructure | | Mahindra Finance | Mahindra Native PG | NBFC's proprietary system | | Shriram Finance | Shriram Native PG | Payment link-based flow |

That's 7+ different gateway integrations for one FD platform. Each with its own:

• API specifications
• Authentication mechanisms
• Hash/signature algorithms
• Callback formats
• Error codes
• Reconciliation processes

How Payment Routing Works

When a customer selects an FD and clicks "Pay," the platform must:

1. Identify the bank from the selected FD product
2. Determine the channel (mobile SDK vs web)
3. Route to the correct gateway based on bank + channel combination
4. Use the correct API keys (some banks have dedicated keys; others share default keys)
5. Generate the correct hash (SHA-512 for PayU, HMAC-SHA256 for Razorpay, custom for ZaakPay)
6. Handle the response in the gateway's specific callback format

This routing logic is the core of payment orchestration for FD distribution.

Gateway-Specific Integration Patterns

Razorpay (Server-to-Server)

Platform creates Razorpay order (amount, receipt: fdId)
    → Razorpay returns orderId + key
    → Frontend opens Razorpay checkout modal
    → User completes payment (UPI/Net Banking)
    → Razorpay sends callback with payment details
    → Platform verifies signature (HMAC-SHA256 with secret)
    → Payment confirmed → FD booking proceeds

For IndusInd and South Indian Bank, dedicated Razorpay API keys are used — meaning the platform manages multiple Razorpay accounts simultaneously.

PayU (Redirect + Hash)

Platform generates SHA-512 hash
    (key|txnid|amount|productinfo|firstname|email|udf1|...|salt)
    → Frontend redirects to PayU payment page
    → User completes payment
    → PayU POST callback with payment status
    → Platform verifies reverse hash
    (salt|status|...|txnid|key)
    → If hash matches: payment confirmed

PayU's hash-based verification is fundamentally different from Razorpay's signature approach. The hash formula includes user-defined fields (udf1-udf5) that carry FD booking metadata.

Cashfree (Server-to-Server + UPI Intent)

Platform creates Cashfree order
    (amount, currency, customer details)
    → Cashfree returns cf_order_id + payment_session_id
    → For UPI Intent: separate API call to create UPI collect/intent request
    → User completes payment
    → Cashfree sends callback with order status
    → Platform verifies using Cashfree SDK verification

Cashfree supports UPI Intent — deep-linking directly to the user's UPI app — which typically has higher success rates than UPI Collect.

ZaakPay (Custom Checksum)

Platform generates checksum using ZaakPay encryption key
    → Creates UPI validate request
    → If valid: creates UPI order
    → User completes payment
    → ZaakPay callback with responseCode
    → responseCode 100 = success; other codes = failure

ZaakPay has bank-specific merchant IDs and keys — Utkarsh SFB uses dedicated credentials, while Shivalik uses shared credentials.

Bank-Native Gateways

Bajaj Finance, Mahindra, and Shriram each have proprietary payment systems:

• Bajaj Finance: Custom API for order creation + periodic status polling (no callback)
• Mahindra Finance: Redirect-based flow with custom callback URLs
• Shriram Finance: Payment link generation — the platform creates a link, user completes payment on Shriram's interface

These native gateways have their own integration patterns, error handling, and reconciliation processes — completely different from third-party gateways.

Payment Methods: UPI vs Net Banking vs NEFT

| Method | Success Rate | Speed | User Experience | |--------|-------------|-------|----------------| | UPI Intent | Highest (70-80%) | Instant | Opens user's UPI app directly | | UPI Collect | Moderate (60-70%) | 30-60 seconds | User enters VPA, approves on their app | | Net Banking | Moderate (55-65%) | 2-5 minutes | Redirects to bank's net banking portal | | NEFT/RTGS | High (once initiated) | 30 min - 2 hours | User initiates separately, submits UTR |

UPI Intent has the best success rates because it minimizes steps — the user simply approves in their UPI app. But not all gateways support UPI Intent for all banks.

UPI Deep Linking

Platforms supporting UPI Intent can deep-link to 11+ UPI apps:

| App | Deep Link | |-----|-----------| | Google Pay | tez://upi/pay | | PhonePe | phonepe://pay | | Paytm | paytmmp://pay | | BHIM | bhim://upi://pay | | WhatsApp Pay | whatsapp://upi/pay | | Amazon Pay | amazonpay://upi/pay |

The platform detects installed UPI apps on the user's device and presents them as direct options — improving success rates by routing to the user's preferred payment app.

Handling Payment Failures

Payment failures are inevitable. In FD booking, ~20-30% of first payment attempts fail. Robust failure handling is critical:

Common Failure Scenarios

| Scenario | Frequency | Handling | |----------|-----------|---------| | Insufficient balance | Common | Immediate failure, user can retry with different account | | Gateway timeout | Moderate | Payment stays pending, background job checks status | | Bank decline | Moderate | Failure with reason, user can try different payment method | | User abandons | Common | Pending until timeout, then marked failed | | Double payment | Rare | Gateway idempotency (orderId-based) prevents duplicate charges | | Callback not received | Occasional | Background job polls gateway API for final status |

The Status State Machine

PENDING (order created, payment initiated)
    → SUCCESS (gateway confirms payment)
    → FAILED (gateway returns failure)
    → TIMEOUT (no response within window)
        → Background job checks status
        → Resolves to SUCCESS or FAILED

For each state transition, the platform:

• Updates the internal payment record
• Sends a webhook to the distribution partner
• Updates the FD booking status accordingly
• If SUCCESS: proceeds with FD creation at the bank
• If FAILED: notifies the user with retry option

Payment Reconciliation

At scale, payment reconciliation is a daily operational task:

Background Jobs

| Job | What It Does | Frequency | |-----|-------------|-----------| | Pending payment checker | Queries gateways for status of pending payments | Every 15 minutes | | Reverse feed processor | Syncs bank-confirmed account numbers and FD status | Hourly | | FD status syncer | Matches payment status with bank FD records | Every 30 minutes |

The Reconciliation Challenge

Consider: a customer pays Rs 50,000 via UPI through Cashfree for a Unity SFB FD. The reconciliation flow involves:

1. Cashfree confirms payment → Payment record updated to SUCCESS
2. Unity SFB creates the FD → FD record linked to payment
3. If there's a mismatch (payment success but FD creation fails) → Refund triggered
4. Refund processed through Cashfree → Refund webhook sent to partner

Each step involves a different system (gateway, bank, internal database, partner webhook) and must be tracked, logged, and reconciled.

Security Considerations

Hash and Signature Verification

| Gateway | Verification Method | Algorithm | |---------|-------------------|-----------| | Razorpay | Webhook signature | HMAC-SHA256 | | PayU | Reverse hash comparison | SHA-512 | | Cashfree | SDK-based verification | Cashfree signature | | ZaakPay | Checksum verification | Custom encryption |

Every callback from every gateway must be cryptographically verified before the payment status is updated. A single unverified callback could result in an FD being created without actual payment.

Additional Security Layers

• IP whitelisting: Bank-native gateways often require the platform's production IPs to be whitelisted
• Credential isolation: Each bank's gateway credentials are stored separately, never shared
• Audit logging: Every payment API call is logged with timestamp, request, and response metadata
• Rate limiting: Per-bank rate limits prevent abuse

Why This Matters for Fintechs

If you're building FD distribution, payment integration alone is a 3-4 month engineering project:

| Component | Effort | |-----------|--------| | 4-5 third-party gateway integrations | 8-12 weeks | | 2-3 bank-native gateway integrations | 6-10 weeks | | Payment routing engine | 2-3 weeks | | Hash/signature verification per gateway | 1-2 weeks | | UPI Intent + deep linking | 1-2 weeks | | Failure handling + retry logic | 2-3 weeks | | Reconciliation jobs | 2-3 weeks | | Refund flows | 1-2 weeks |

And this is just the payment layer — on top of KYC, bank integration, and compliance work.

Infrastructure platforms that have already built and battle-tested this payment orchestration across millions of transactions offer a significant shortcut. One integration replaces 7+ gateway integrations and all the routing logic, failure handling, and reconciliation.

---

Blostem's payment orchestration handles Razorpay, PayU, Cashfree, ZaakPay, and bank-native gateways — routing to the correct gateway per bank, automatically. See our infrastructure.