Payment Gateway Questions & Answers

Honestly, this is one of those boring but super important changes that came after the Sept 15, 2025 UPI update. NPCI bumped limits for certain categories like term deposits, insurance premiums, and capital market investments up to ₹10L per day in some cases.

The problem? Most users (and even devs) don’t realize their bank or PSP (PhonePe, Paytm, Razorpay, etc.) might already support higher UPI limits. So your ERP needs to tell them in real-time whether they’re good to go for a high-value payment.

Here’s how I’d approach it:

• Check the user’s actual UPI limits via the PSP API

Most UPI PSPs now let you query a user’s limit metadata using their VPA.
So when someone enters something like user@icici, you hit an endpoint like:
GET /upi/v1/limits?vpa=user@icici

and get back a response that tells you if that category (term deposits = TDOPEN) supports higher limits.

If it says eligible: true, show a banner that says:

Your bank supports high-value UPI deposits (up to ₹10L). You can proceed safely.

If not, fallback to a gentle warning:

Your current UPI account may have a ₹1L cap. Try NEFT/RTGS for larger deposits.

• Use the new NPCI purpose codes

UPI transactions now carry category tags TDOPEN for term deposits, INSURANCE, CAPMKT, etc.

Your ERP should use those to check if the user’s bank supports higher caps for that specific purpose.

If the purpose code is recognized and supported, show that eligibility message.

If not, hide the high-limit banner to avoid confusion.

• Add dynamic messages in the payment screen

Instead of one static Pay via UPI button, make it context-aware:

• If eligible → show High-value UPI enabled (₹10L cap)
• If not → show UPI limit ₹1L try NEFT for larger deposits

Little thing, but it saves tons of failed transactions and support tickets.

• Tag this info in backend logs

Once the eligibility is confirmed, tag the transaction with a flag like
upi_high_value=true.

This helps with reconciliation and audit trails later especially when settlement teams are figuring out why some UPI payments show up in the high-value bucket.

• Show it on receipts too

After payment succeeds, include a line like:
Paid via UPI (High-Value Limit Enabled ₹10,00,000 cap).
Auditors love this kind of transparency.

Finance teams should:

• Track daily aggregate UPI inflows for term deposits (purpose_code = INVS_TD)
• Set threshold alerts (85% and 100%)
• Watch for settlement delays and ledger mismatches
• Use Slack + webhook-based notifications
• Auto-switch to fallback methods when nearing daily cap

Identify the merchant category upfront.

When your checkout loads, tag the transaction as CREDIT_CARD_BILL_PAYMENT (using MCC or an internal category field). This tells your backend to pull the right UPI cap for that transaction type. Fetch the correct category limits.

Your backend (or payment gateway) should maintain a small lookup table synced with NPCI/PSP rules, for example:

• Credit Card Bill Payments → ₹2,00,000 per txn, ₹10,00,000 per day
• Regular P2M → ₹1,00,000 per txn

You can either store this locally or fetch it from the gateway during checkout initialization.

Validate before initiating UPI intent or collect.

Before firing the UPI intent (deep link or QR), run a quick check:

if (txn_amount > category_limit_per_txn || 

daily_total_for_user + txn_amount > category_limit_daily) {

showError(This payment exceeds your UPI limit for credit card bills. Try a smaller amount or net banking.)

blockProceed()

}

This prevents limit-related declines after the user’s PSP gets involved — saving you from failed payment frustration.

Add real-time PSP validation (optional but ideal).

Some banks and PSPs (like PhonePe or Google Pay) will start returning metadata in their /validate or /collect APIs with updated caps. If available, use that response to dynamically override your local limits.

Show clear user messaging.

If someone tries to pay ₹3 lakh and the per-transaction cap is ₹2 lakh, show a message like:

UPI supports up to ₹2,00,000 per transaction for credit card bill payments. You can split this into multiple payments or use net banking.

That’s way better than just showing a generic Transaction failed.

Log validations for audits.

Save each pre-validation check (amount, cap, PSP handle, timestamp) — NPCI and auditors might later require evidence that you enforced caps correctly

• Differentiate high-value UPI transactions in the ledger.

Create a separate sub-ledger or GL code for UPI, Credit Card Bill Payments (High-Value) instead of lumping everything into your generic UPI receipts account. This helps auditors trace which transactions used the extended UPI limit versus regular consumer payments.

• Update settlement mapping logic.

Since large-value UPI payments may settle through different PSP routes or delayed settlement windows (especially if they’re processed after the daily cutoff), your engine should tag settlement entries with PSP IDs, timestamps, and settlement references from the bank/NPCI. This ensures that when reconciliation happens, you’re not mismatching next-day settlements with same-day ledger postings.

• Handle split and partial payments cleanly.

If your checkout auto-splits transactions to stay under the per-transaction cap, map each split leg to a unique transaction reference but post them under the same invoice ID. The GL should record both the original invoice and each UPI leg separately so finance can see exactly how the total was cleared.

• Introduce a Pending Settlement interim ledger.

For high-value payments that settle after a delay (which happens with some PSPs on weekends or after cap-based processing windows), the receipt should first hit a Pending UPI Settlement ledger and only move to Final UPI Receipts after the settlement webhook confirms success.

• Include UPI reference IDs in journal entries.

Make the NPCI or PSP UPI reference number part of your journal entry metadata (not just the transaction table). This helps your finance team trace payments directly to settlement files during audits.

• Apply updated reconciliation rules.

Ensure your reconciliation engine checks that the PSP settlement file total matches both your UPI – Credit Card Bill Payments (High-Value) ledger and the Pending Settlement ledger before closing the day’s books.

When your POS system hits the new UPI caps mid-checkout for a term deposit opening, the key is to fall back gracefully without making the customer feel like the transaction failed. After September 15, 2025, NPCI allows higher UPI limits (up to ₹10 lakh/day) for verified categories like term deposits, but if a customer hits that cap (either per-transaction or daily), your POS needs to automatically suggest alternate, compliant payment methods so the flow doesn’t break.

Here’s how to handle it smartly:

• Detect limit breaches early.

Before the UPI intent even fires, your POS should validate the amount against the merchant’s configured NPCI category cap and the customer’s remaining daily quota. If it’s close to the cap (say, above 90%), show a pre-check message like This UPI payment may exceed your daily limit. Would you like to split or use another method? This saves users from failed transactions at the final step.

• Offer context-aware fallback options.

For high-value term deposits, don’t just say use another method. Suggest specific alternatives that suit the context:

• Netbanking (NEFT/RTGS): Ideal for large transactions above ₹2 lakh. Most customers opening term deposits are already comfortable with it.
• Debit card (linked to same bank): For users who prefer to stay within one ecosystem some banks allow instant deposit funding this way.
• IMPS (for smaller spillover amounts): Works if only a few thousand rupees exceed the UPI cap.
• In-branch collection or cheque: As a last resort for users uncomfortable with online flows or those hitting regulatory limits.
•  Auto-split suggestion for UPI itself.

If the total is ₹10.5 lakh and the customer has ₹9.5 lakh remaining under their UPI limit, the POS should automatically prompt: You can complete ₹9.5 lakh now via UPI and pay the remaining ₹1 lakh via netbanking. Split flows like this help keep conversion rates high while staying compliant.

• Persist the context.

Make sure the fallback options carry over the customer’s original term deposit details amount, duration, account so they don’t have to re-enter everything when switching methods. This makes the fallback feel like a continuation, not a restart.

• Use real-time PSP feedback.

If the PSP returns a response like TXN_LIMIT_EXCEEDED or DAILY_CAP_REACHED, your POS should map that error to a user-friendly suggestion, not a dead-end error. Example: This payment exceeds your UPI daily limit. You can continue securely using netbanking or card.

• Log fallback triggers for compliance.

Each fallback should be recorded with details like original payment method, failure code, chosen alternative, and timestamp. NPCI and auditors often ask for this data when verifying compliance with limit rules.

Your reconciliation software should group split UPI payments under one investment, use a clearing-to-final-ledger flow, tag transactions with purpose codes, and ensure cross-midnight and partial settlements are posted accurately. Think of it as turning messy, multi-part UPI inflows into one clean, auditable record for your capital market customers.

To simplify audits and ensure compliance:

• Add a purpose code field in your UPI integration (INVS_TD or equivalent).
• Map it through your billing, ledger, and reconciliation modules.
• Validate it before posting any high-value term deposit receipt.
• Surface it in reports to make audit trails easy and RBI-aligned.

To auto-split UPI payments for large credit card bills:

• Detect when the amount exceeds the cap.
• Split it into multiple capped UPI requests.
• Chain them with sequential confirmation.
• Show progress in real time.
• Reconcile all parts under one parent transaction.
• Handle partial failures gracefully.

It’s basically like building a mini-orchestrator for multi-leg UPI payments, but once it’s done, your users will be able to pay ₹2L+ bills smoothly while you stay compliant with NPCI’s caps.

If your ERP finance module handles credit card bill payments via UPI, the September 2025 rule changes (with higher category-wise UPI limits) mean your settlement and ledger logic needs a refresh. Without it, you’ll end up with misclassified receipts, reconciliation headaches, or incorrect tax postings.

Here’s what you should update:

Settlement Rules- Separate High-Value Flows

• Why: NPCI now allows higher daily caps for certain categories like credit card bills, but these still need to be settled distinctly.
• What to do:
• Maintain a dedicated settlement batch for high-value (>₹1L) credit card UPI receipts.
• Use NPCI Transaction Reference (UTR) as the primary settlement key.
• Ensure T+0 settlement tagging for same-day clearing if the PSP supports it.
• If your acquirer delays settlements past midnight, split into pre-midnight and post-midnight batches to align with daily cap windows.

Ledger Mappings- Separate Customer Advance vs. Final Payment

• Why: Sometimes, partial UPI payments post before full bill amount clears (due to per-transaction limits).
• What to do:
• Map partial UPI receipts to Customer Advance (Liability).
• Only move to Credit Card Bill Payment (Revenue/Clearing) once the full invoice is settled.
• Automate the transfer between these ledgers when the ERP detects full bill paid.

UPI Purpose Code Mapping

• Why: Credit card bill payments must use purpose code CCBP (or the category NPCI defines).
• What to do:
• Add logic to validate purpose codes during settlement posting.
• Mismatch? Route to an Unclassified Receipts ledger for manual review.
• This prevents compliance flags during audits.

Fee and MDR Accounting

• Why: UPI for credit card bill payments might have different MDRs depending on the issuer/acquirer.
• What to do:
• Separate fee ledger mappings for UPI vs. non-UPI settlements.
• Record net settlement = Gross – MDR – PSP Fee, and post to distinct ledger accounts.
• Include reference to the PSP handle for audit clarity.

Reconciliation Ledger Logic

• Why: When a transaction exceeds a per-transaction cap, UPI might split it into multiple payments or delay one part.
• What to do:
• Add a Transaction Correlation ID field to tie all parts of a single customer payment.
• During reconciliation, only mark the invoice paid when all linked UPI payments clear

To simplify audits and reconciliation, your payment gateway should:

• Include txnPurpose: CCBP for all credit card bill UPI transactions.
• Map and validate MCCs to correct NPCI purpose codes.
• Carry the same tags through settlement, refunds, and reports.

That one field saves hours of cleanup during audits and ensures NPCI, banks, and your accounting reports all speak the same language.