What is an automatic payment in PayPal, and how do I update or cancel one?

If your POS system accepts UPI payments for term deposit openings, you’ll need to tweak both your settlement and ledger rules to handle the new high-value UPI limits properly. Since September 15, 2025, the NPCI lets verified categories like term deposits go up to ₹10 lakh per day — but that also means your system has to treat these transactions differently from normal retail payments.
First, update your settlement rules. Tag every UPI transaction meant for term deposits with the correct NPCI purpose code INVS_TD. This ensures they aren’t mixed with normal sales payments. Route them through a separate investment or deposit settlement batch rather than the standard POS batch, because banks may process these through different merchant codes and timings. Large-value UPI payments (above ₹2 lakh) often settle on a T+1 basis, so your settlement logic must support delayed posting. Also, only allow routing through verified PSP handles that actually support high-value UPI; not every PSP does. Finally, your reconciliation flow should match each incoming UPI receipt against a term deposit creation request so that the finance team never sees unlinked receipts in their end-of-day reports.
Next, update your ledger mapping. In normal retail flows, a UPI receipt credits sales revenue but for term deposits, that’s incorrect. Instead, when a customer opens a term deposit via UPI, the entry should debit the bank (UPI receipts) and credit a Term Deposit Liability account. Once the term deposit is actually created or confirmed in the core banking system, that liability should move to the Term Deposit Principal account. If a refund happens before creation, you’d reverse it by debiting the liability and crediting Bank UPI Refunds Payable.
You’ll also want to add some extra controls in your posting logic. Always store the NPCI purpose code (INVS_TD) in your transaction records so audits can identify investment-linked UPI flows. Maintain a link between the UPI Reference ID and the Term Deposit ID to make reconciliation painless. Set up a daily aggregate view to make sure the total UPI receipts tagged as INVS_TD don’t exceed ₹10 lakh per merchant per day. And log PSP handle details and payer VPAs to meet compliance requirements.
Before settlement posting, the POS should also verify a few things: that the PSP handle supports high-value UPI, the transaction status is successful, the settlement window hasn’t expired, and the total daily inflows for that category are still within limit. If any of these checks fail, the transaction should be flagged for manual review instead of getting auto-posted.

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.

So, after the September 2025 UPI rule change, credit card bill payments can have higher daily caps but still have a per-transaction cap meaning a single large bill might need to be split into multiple UPI transactions. If your reconciliation software doesn’t support this auto-split workflow, your downstream ledgers and settlement files are going to look messy real fast.

Here’s how you should design those workflows:

• Add a pre-reconciliation validation layer:

When your system ingests transaction data, it should check whether any single bill payment exceeds the UPI per-transaction cap (say ₹2 lakh). If yes, automatically flag it as a split-required transaction and queue it for sub-transaction generation.

• Auto-split logic with parent-child mapping:

The software should create multiple child transactions, each within the cap (e.g., a ₹4 lakh bill splits into two ₹2 lakh UPI transactions). Each child transaction should carry the same parent ID and reference the same payer details for unified tracking.

• Assign sequence and settlement references:

Add a split sequence number and link all parts under a single Parent Settlement ID. This helps during reconciliation when settlement confirmations come back separately from the PSP or bank.

• Update reconciliation matching rules:

During matching, your software needs to sum all child transactions belonging to a parent and match the combined total against the source invoice or card bill. That way, you don’t show false partial match errors in reports.

• Add audit tagging for split payments:

Every child transaction should retain the same purpose code (P1003 for credit card bills) but should also include a split index field (1/2, 2/2, etc.) for audit and traceability.

• Handle reversals cleanly:

If one of the split payments fails or reverses, your reconciliation system should automatically flag the parent as partially settled and initiate retry workflows only for the failed portion not the entire amount.

• Integrate user and finance alerts:

Build alerts like Bill partially settled ₹2 lakh pending due to per-transaction cap so finance teams know whether to trigger retries or alternative payment routes like NEFT.

Make your invoicing tool smart enough to notice when someone’s trying to pay more than the UPI limit, quietly break it into smaller transactions, and handle them one by one in the background. Then stitch it all together so your books still show a single payment. It’s mostly about saving the customer from Payment Failed – Limit Exceeded errors and your finance team from reconciliation nightmares.

Simulate high-value UPI transactions across multiple PSPs.

Start with mock payments that hit different slabs — ₹50K (below cap), ₹1L (old cap), ₹5L, and ₹10L (new limit). Make sure to include both payer-verified and non-verified scenarios. You want to confirm that your refund logic only triggers for transactions that were actually successful and within NPCI’s allowed range.

Test full and partial refunds

Run test cases for both:

• Full refund: ₹10L payment reversed completely.
• Partial refund: ₹10L payment, ₹2L refunded.

Verify that your PSP APIs (like Razorpay, Cashfree, or Paytm) correctly handle the refund_reference_number and that the original UPI transaction ID maps properly to the refund in your ledger.

Validate refund window and cap handling.

Some PSPs impose refund windows or lower refund caps for large-value UPI payments. Your marketplace should log the error gracefully if a refund attempt exceeds the PSP’s refund time window or refund amount limit.

Chargeback scenarios.

Simulate customer-initiated chargebacks (where the user disputes the payment through their bank). Make sure your platform captures the chargeback notification webhook and reconciles it against the original transaction. Your ledger should automatically move the transaction from Settled → Under Dispute → Reversed once confirmed.

Test multi-split transaction refunds.

For cases where you auto-split a ₹10L bill payment into two ₹5L transactions, ensure your refund logic tracks both sub-transactions independently. If only one leg fails, the refund should still reconcile correctly in your GL.

Reconciliation and audit trails.

Every refund or chargeback should flow through your UPI settlement reports and update the GL with the same txn_id or upi_ref_id that appeared in the original payment. If the PSP changes reference IDs for refunds, your QA should flag that to finance.

Stress test response delays.

UPI refunds can take minutes (sometimes hours) to process, especially for high-value categories. Check that your marketplace gracefully handles delayed PENDING → SUCCESS updates and retries webhook confirmations without creating duplicates.