Built-In Payment Gateway Fraud Detection in India (2026): The Rule Engine and Risk Scoring Checklist

Built-in payment gateway fraud detection assesses transaction risk within the payment flow using rules, behavioural signals and risk models. For online businesses in India, the evaluation should cover fraud detection, merchant-configurable controls and the visibility available into risk decisions.

Razorpay’s documented capabilities include its AI/ML-based Shield Risk Engine for cross-border payment risk and merchant-created block rules in the Risk Analytics Dashboard for Indian exporters. Ecommerce businesses can separately use Magic Checkout for COD risk controls and RTO review workflows.

Imagine 300 small-value card attempts reaching your checkout in four minutes. An amount-only rule might miss the pattern, while a poorly tuned velocity rule could also flag legitimate buyers. This checklist explains which capabilities to verify, how rules and scoring can work together, and how to evaluate fraud controls without unnecessarily declining genuine customers. Feature availability, activation and payment-method coverage should be confirmed for the merchant account.

How does Razorpay support fraud detection, rule engines, and risk scoring?

These examples cover different products and transaction types. Confirm which controls are enabled, which can be configured by the merchant, and which decisions remain with Razorpay or the issuer.

For the baseline layer itself, see this payment gateway tokenisation and encryption checklist.

TransUnion’s H1 2026 report records a suspected digital fraud attempt rate of 7.1% for India and 3.8% globally in 2025. The measure covers attempted digital activity observed through its intelligence network and includes specified policy violations. It is not a confirmed payment-fraud loss rate or a Razorpay performance metric.

What is the difference between a rule engine and a risk score?

A rule engine evaluates explicit conditions, such as repeated failed payment attempts within a defined time window. A risk model combines available signals to estimate or categorise risk. Some systems use weighted points, while others use model outputs or risk tiers. Scores and thresholds are product-specific and should not be assumed to mean the same thing across providers.

An illustrative evaluation flow is:

1. Collect the transaction, device, account, and instrument signals available to the integration.
2. Apply verified blocklists and hard policy conditions.
3. Evaluate velocity and other contextual signals.
4. Combine signals using the supported model or scoring method.
5. Map the result to an action supported by that payment or order flow.
6. Record the decision, relevant reasons and rule or model version.

A low-risk result does not waive mandatory authentication. Review timing also depends on the product: an order or fulfilment review should not be described as a universally available pause in live payment authorisation.

Pro tip: Where the product supports it, test a new rule in shadow mode before enforcing it. Compare the expected trigger rate, review volume and approval impact with the outcomes from labelled transactions. If shadow mode is unavailable, agree on a controlled pilot and rollback process.

The six-category rule engine checklist

Use these questions to assess the controls relevant to your payment mix. The examples are evaluation scenarios, not Razorpay defaults or production thresholds.

For every rule, record the signal, observation window, threshold, action, owner and exceptions. Select thresholds through analysis and controlled testing of the merchant’s traffic.

For card payments, evaluate issuing-country, billing and device information together where those signals are available. A mismatch is a reason to investigate within the supported control framework, rather than proof of fraud by itself.

Razorpay’s Address Verification System is an on-demand feature for international payments using US, UK and Canada cards. Its documented workflow uses issuer address-match results to authorise or decline a payment. Do not assume AVS is available on domestic cards or that every merchant can replace a decline with a custom score.

Use gateway-provided instrument identifiers and supported device signals for velocity analysis. Do not collect raw card numbers or CVV for this purpose, and do not assume one token identifies the same card across every merchant and integration.

What should merchants verify for UPI fraud controls?

For UPI acceptance, confirm that the payment belongs to the expected order, that the paid amount matches, and that fulfilment uses trusted server-side payment confirmation. Where supported, assess repeated attempts, unusual retry patterns and mandate status for recurring collections.

Do not assume a merchant gateway can inspect VPA age, impose a new-beneficiary cooling-off period or control every bank-side authentication decision. Ask which UPI signals and actions the provider actually exposes. Keep merchant acceptance controls separate from bank or PSP transfer controls.

Device and network signals can help identify unusual patterns when combined with account and transaction context. Where available, evaluate proxy use, session changes and device reuse across accounts. Account for legitimate shared devices and networks before making a blocking decision.

Did you know: A risk decline records a payment rejected because of perceived risk. It does not establish that the buyer was fraudulent or that the decline was incorrect. Distinguishing those outcomes requires further evidence.

How should a business interpret risk scores?

For an educational weighted-points example, the maximum contributions could be velocity 20, device and account novelty 15, geography 15, instrument mismatch 15, historical fraud linkage 20, and merchant context 15. These add up to 100 possible points. The example is not Razorpay’s published model, a recommended production configuration, or a calibrated probability of fraud.

A total of 50 points would not automatically mean a 50% fraud probability. Set action thresholds using labelled outcomes, review capacity, and the approval impact for the relevant product and transaction type.

Pro tip: Where signup and login signals are lawfully collected and available, evaluate whether they add useful context at checkout. Validate their predictive value rather than assuming phone age, email age, or device data is always available or decisive.

RBI authentication and fraud-control responsibilities

RBI’s Authentication Mechanisms for Digital Payment Transactions Directions, 2025 require compliance from 1 April 2026. Domestic digital payments require at least two distinct authentication factors unless exempted, with at least one dynamic factor for transactions other than card-present transactions.

The separate 1 October 2026 cross-border provisions concern card issuers and Indian-issued cards used with overseas-acquired merchants. They include validation of non-recurring CNP payments when authentication is requested, plus a risk-based mechanism for all cross-border CNP transactions. Additional risk checks do not replace the applicable authentication minimums.

RBI’s Payment Aggregator Master Direction requires fraud-prevention and information-security controls and an annual system audit, including a cybersecurity audit, by CERT-In empanelled auditors. It does not prescribe this article’s illustrative score weights or a universal per-rule logging template.

What should businesses confirm before choosing a fraud-control setup?

Ask which payment methods the controls cover, whether rules can be configured by your team, whether risk reasons or scores are visible, and which actions can be automated. Request the documentation for the relevant dashboard, workflow or API rather than treating a general fraud-detection claim as proof of every capability.

Also distinguish the Shield Risk Engine from participation in Razorpay’s Shield chargeback program. The program requires enrollment and applies to qualifying cross-border export payments under its coverage conditions and exclusions.

Rules provide explicit conditions; models help assess combinations of signals. Their interaction depends on the product. Neither a rule trigger nor a high score, by itself, should be described as conclusive proof of fraud. For the broader framework, see how payment gateways reduce fraud risk.

How to reduce false declines while managing fraud

False declines turn away legitimate customers and can reduce revenue. Track approval rates, review volume, confirmed fraud and estimated false positives together, using comparable transaction cohorts. A risk decline is not automatically a false decline.

Depending on the supported payment or order flow, responses may include:

1. Continue through the normal payment process and applicable authentication.
2. Apply additional verification where supported and justified.
3. Hold an order for review within a documented SLA where the product permits it.
4. Decline or cancel under the applicable policy when the evidence supports that action.

Do not automatically add a customer to a blocklist merely because a score is high. When a rule’s decline rate rises, investigate its trigger mix, legitimate customer impact and delayed fraud outcomes before deciding to retune or retire it.

Pro tip: Include approval impact and false-positive estimates in the same review as fraud losses. Record uncertainty where the outcome of a blocked attempt cannot be established.

Rule governance and decision records

Use a documented rule lifecycle: draft, test without enforcement where supported, pilot, activate and review. Give each rule a named owner, rationale, review date and rollback process. This is recommended operational practice; confirm the regulatory requirements that apply to your organisation.

1. Draft and document. Record the hypothesis, available signals and expected trigger volume.
2. Test. Check the proposed rule on historical or shadow traffic where available.
3. Pilot. Measure approval impact and review workload on a controlled cohort.
4. Activate. Record the approver, rule version and effective date.
5. Monitor. Review approval rates, risk declines, confirmed fraud and false-positive estimates, allowing for reporting delays.
6. Review, retune or retire. Document the decision and supporting evidence by the review date.

Retain decision records sufficient to investigate and reproduce the relevant outcome:

• Transaction or event identifier.
• Relevant reason codes and signal summaries.
• Rules or model version used.
• Score or risk tier where available.
• Decision, action and timestamp.
• Applicable approval and change-control record.

Exclude raw card numbers, CVV, OTP and unnecessary personal data. Define retention periods for each record category with the compliance team and restrict access to authorised users.

Keep COD and RTO controls separate from prepaid payment fraud

COD orders introduce fulfilment and return risk as well as possible abuse. An RTO event does not by itself prove fraud.

Razorpay Magic Checkout supports COD allow/block controls using specified customer and delivery attributes when COD Intelligence is enabled. A separate manual-review workflow lets merchants configure approve, hold or cancel actions by RTO risk level.

Razorpay’s on-demand RTO Intelligence offering provides order-risk information and reasons that can inform COD availability and fulfilment decisions. Confirm enablement and integration requirements for the account.

Pro tip: Review COD settings separately from card and UPI risk rules. Measure their effect on RTO, prepaid conversion and legitimate order completion.

When should a business reassess its rules and risk models?

Begin with the controls available through the selected provider and the risks relevant to your business. A built-in provider model may already use network-level data; a merchant does not necessarily need months of its own training data before using it. If building a separate model, assess data quality, outcome labels, validation and operational readiness before deployment.

Review the setup when:

• Rule conflicts make the intended decision unclear.
• Review workload grows faster than the team’s capacity.
• Legitimate customers are increasingly affected.
• Confirmed fraud patterns are not adequately covered.
• New patterns repeatedly require changes.

Where rules and models are combined, document how conflicting decisions are resolved. Preserve mandatory policy controls and validate the effect of each change rather than assuming a larger rule count or a newer model is automatically better.

Frequently asked questions

Does Razorpay offer built-in fraud and risk controls?

Razorpay documents AI/ML payment-risk assessment, international Risk Analytics block rules and separate Magic Checkout COD/RTO controls. Availability and merchant configuration depend on the relevant product and account setup.

What should I ask about a payment gateway’s rule engine?

Ask which signals and time windows are supported, who can change rules, which payment methods are covered, what actions are available and how changes can be tested and reversed.

Can merchants access every payment risk score through an API?

Do not assume this. Confirm the score, risk tier or reason codes exposed by the specific product. Razorpay documents a separate on-demand RTO Intelligence API for order-risk information; that does not establish a universal numerical card or UPI fraud-score API.

How should fraud-rule thresholds be selected?

Use labelled outcomes and controlled testing to balance fraud exposure, approval impact and review capacity. A sample point model is an illustration, not a production threshold recommendation.

Are COD risk scoring and payment fraud scoring the same?

No. COD/RTO controls address order and fulfilment outcomes. Card and UPI payment-risk controls address their respective transaction flows. Assess each product’s supported data and actions separately.

Use this checklist to document the controls your business needs and confirm their scope, availability and ownership. Explore Razorpay’s Payment Gateway, its International Payments offering and Magic Checkout for the relevant payment and order flows.