{"id":19014,"date":"2026-09-17T10:34:43","date_gmt":"2026-09-17T05:04:43","guid":{"rendered":"https:\/\/learn.razorpay.in\/learn\/?p=19014"},"modified":"2026-09-17T10:34:43","modified_gmt":"2026-09-17T05:04:43","slug":"payment-timeout","status":"publish","type":"post","link":"https:\/\/razorpay.com\/learn\/payment-timeout\/","title":{"rendered":"Payment Timeout vs. Late Authorisation: A Merchant&#8217;s Guide to Handling Delayed Payments"},"content":{"rendered":"<p><span style=\"font-weight: 400;\">A <\/span><b>payment timeout<\/b><span style=\"font-weight: 400;\"> occurs when a payment gateway does not receive a bank&#8217;s final response within the expected window. A <\/span><b>late authorisation<\/b><span style=\"font-weight: 400;\"> occurs when that response arrives afterward, confirming the transaction actually succeeded. Knowing how to <\/span>handle late authorised payments is what separates a smooth recovery from a support-ticket backlog and customer churn.<\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_80 counter-hierarchy ez-toc-counter ez-toc-transparent ez-toc-container-direction\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Table of Contents<\/p>\n<label for=\"ez-toc-cssicon-toggle-item-6aab8f9dcc4e0\" class=\"ez-toc-cssicon-toggle-label\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/label><input type=\"checkbox\"  id=\"ez-toc-cssicon-toggle-item-6aab8f9dcc4e0\"  aria-label=\"Toggle\" \/><nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/razorpay.com\/learn\/payment-timeout\/#What-Happens-During-a-Payment-Timeout-From-Created-to-Late-Authorisation\" >What Happens During a Payment Timeout: From Created to Late Authorisation<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/razorpay.com\/learn\/payment-timeout\/#Payment-Capture-Settings-Capture-or-Refund-Late-Authorised-Payments-by-Business-Model\" >Payment Capture Settings: Capture or Refund Late Authorised Payments by Business Model<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/razorpay.com\/learn\/payment-timeout\/#How-to-Handle-Late-Authorised-Payments-Webhooks-and-Idempotency-Keys\" >How to Handle Late Authorised Payments: Webhooks and Idempotency Keys<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/razorpay.com\/learn\/payment-timeout\/#How-to-Communicate-a-Payment-Timeout-to-Customers\" >How to Communicate a Payment Timeout to Customers<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/razorpay.com\/learn\/payment-timeout\/#Reconciling-Late-Authorisation-and-Refunds\" >Reconciling Late Authorisation and Refunds<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/razorpay.com\/learn\/payment-timeout\/#FAQs\" >FAQs<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"What-Happens-During-a-Payment-Timeout-From-Created-to-Late-Authorisation\"><\/span><span style=\"font-weight: 400;\">What Happens During a Payment Timeout: From Created to Late Authorisation<\/span><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><span style=\"font-weight: 400;\">A <\/span><b>payment gateway timeout<\/b><span style=\"font-weight: 400;\"> doesn&#8217;t mean a payment has failed. It means the gateway didn&#8217;t get bank confirmation within the standard cutoff, typically around 10 minutes.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Here&#8217;s what happens, step by step:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Interruption<\/b><span style=\"font-weight: 400;\">: The customer submits their OTP or approves the UPI request. The bank processes the debit, but the confirmation doesn&#8217;t reach the gateway in time due to network latency or <\/span><b>bank server downtime<\/b><span style=\"font-weight: 400;\">.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Timeout window<\/b><span style=\"font-weight: 400;\">: The gateway marks the <\/span><b>payment status created<\/b><span style=\"font-weight: 400;\">, then updates it to <\/span><span style=\"font-weight: 400;\">Failed<\/span><span style=\"font-weight: 400;\"> after the cutoff.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Polling phase<\/b><span style=\"font-weight: 400;\">: The gateway continues polling the bank&#8217;s servers for a defined window, often up to 72 hours, checking the <\/span><b>transaction status<\/b><span style=\"font-weight: 400;\">.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Late authorisation<\/b><span style=\"font-weight: 400;\">: If the bank retroactively confirms the debit succeeded, the gateway updates the payment to <\/span><span style=\"font-weight: 400;\">Authorized<\/span><span style=\"font-weight: 400;\">. This delayed confirmation is the <\/span>late authorisation.<\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\">This lifecycle is why a <\/span>failed payment bank debited<span style=\"font-weight: 400;\"> complaint isn&#8217;t necessarily a bug. It&#8217;s usually a payment still waiting on step 3 or 4.<\/span><\/p>\n<p><a href=\"https:\/\/razorpay.com\/docs\/payments\/payments\/late-authorisation\" target=\"_blank\" rel=\"noopener\">Read More\u00a0<\/a><\/p>\n<h2><span class=\"ez-toc-section\" id=\"Payment-Capture-Settings-Capture-or-Refund-Late-Authorised-Payments-by-Business-Model\"><\/span><span style=\"font-weight: 400;\">Payment Capture Settings: Capture or Refund Late Authorised Payments by Business Model<\/span><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><span style=\"font-weight: 400;\">How you respond to a late-authorized payment depends on what you&#8217;re selling. Auto-fulfilling an order a day late can damage trust in quick commerce; auto-refunding a SaaS subscription unnecessarily creates friction for a customer who already has access.<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Business Model<\/b><\/td>\n<td><b>Operational Risk<\/b><\/td>\n<td><b>Default Strategy<\/b><\/td>\n<td><b>Action Rule<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Quick commerce &amp; food delivery<\/span><\/td>\n<td><span style=\"font-weight: 400;\">High (item no longer needed)<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Auto-refund<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Reject late capture; trigger an <\/span><b>auto-refund<\/b><span style=\"font-weight: 400;\"> immediately<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Standard e-commerce (physical goods)<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Medium (inventory lock, shipping delay)<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Dynamic capture<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Capture and ship if inventory is available; refund if not<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">SaaS &amp; digital subscriptions<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Low (no physical inventory cost)<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Auto-capture<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Capture funds and grant access immediately<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Event ticketing &amp; travel<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Critical (seat\/room may be reallocated)<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Strict timeout refund<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Cancel the booking on timeout; refund late-authorized funds<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">Getting this right depends on your <\/span><b>payment capture settings<\/b><span style=\"font-weight: 400;\">. Manual capture gives your backend the final say on whether to claim funds or reverse them, based on real-time inventory or booking state rather than the gateway&#8217;s default behavior.<\/span><\/p>\n<h2><span class=\"ez-toc-section\" id=\"How-to-Handle-Late-Authorised-Payments-Webhooks-and-Idempotency-Keys\"><\/span><span style=\"font-weight: 400;\">How to Handle Late Authorised Payments: Webhooks and Idempotency Keys<\/span><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Relying on a browser redirect to confirm payment status is a common architectural gap. If a customer closes the tab during a <\/span>payment timeout<span style=\"font-weight: 400;\">, your system never receives that redirect, but the payment may still resolve successfully on the bank&#8217;s side.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Two things prevent this from becoming a reconciliation problem:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Subscribe to the payment authorized webhook.<\/b><span style=\"font-weight: 400;\"> When a bank confirms a previously timed-out transaction, the gateway fires a server-to-server event. Your backend should update order status from this event, not from frontend state.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Use idempotency keys.<\/b><span style=\"font-weight: 400;\"> Customers who see a timeout often click &#8220;retry&#8221; immediately. Attaching a unique <\/span><b>idempotency key<\/b><span style=\"font-weight: 400;\"> (such as your order ID) to each payment request ensures that if the original attempt later resolves as a <\/span>late authorisation<span style=\"font-weight: 400;\">, your system won&#8217;t create a duplicate order or charge the customer twice.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Together, these close the two most common failure modes: silently missed confirmations and double charges, both major contributors to <\/span>customer abandonment<span style=\"font-weight: 400;\"> during checkout.<\/span><\/p>\n<h2><span class=\"ez-toc-section\" id=\"How-to-Communicate-a-Payment-Timeout-to-Customers\"><\/span><span style=\"font-weight: 400;\">How to Communicate a Payment Timeout to Customers<\/span><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Proactive messaging during the unresolved window reduces support volume and chargeback risk. Keep it factual, not reassuring with numbers you can&#8217;t guarantee:<\/span><\/p>\n<p><b>On timeout:<\/b> <i><span style=\"font-weight: 400;\">&#8220;Your payment for Order #{{Order_ID}} is taking longer than expected to confirm. If your account was debited, no action is needed yet, we&#8217;ll update your order automatically once your bank confirms the status.&#8221;<\/span><\/i><\/p>\n<p><b>On late authorisation:<\/b> <i><span style=\"font-weight: 400;\">&#8220;Your payment for Order #{{Order_ID}} has now been confirmed. Your order is processed, view your receipt here: {{Link}}.&#8221;<\/span><\/i><\/p>\n<p><span style=\"font-weight: 400;\">Avoid stating specific refund timelines in customer-facing copy unless your bank or gateway SLA explicitly guarantees one. Point to order status instead.<\/span><\/p>\n<h2><span class=\"ez-toc-section\" id=\"Reconciling-Late-Authorisation-and-Refunds\"><\/span><span style=\"font-weight: 400;\">Reconciling Late Authorisation and Refunds<\/span><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Unresolved late authorisations complicate monthly <\/span>reconciliation<span style=\"font-weight: 400;\"> if not tracked separately from standard captures and refunds. Merchants should confirm with their payment provider how <\/span><b>MDR fees<\/b><span style=\"font-weight: 400;\"> are handled on transactions that are authorized late and subsequently refunded, since this can vary by processor and shouldn&#8217;t be assumed. Building a ledger rule that flags <\/span><span style=\"font-weight: 400;\">Created<\/span><span style=\"font-weight: 400;\">, <\/span><span style=\"font-weight: 400;\">Failed<\/span><span style=\"font-weight: 400;\">, and late-<\/span><span style=\"font-weight: 400;\">Authorized<\/span><span style=\"font-weight: 400;\"> states separately keeps monthly reconciliation clean.<\/span><\/p>\n<h2><span class=\"ez-toc-section\" id=\"FAQs\"><\/span><span style=\"font-weight: 400;\">FAQs<\/span><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><b>#1 What causes a failed payment bank debited issue?<\/b><b><br \/>\n<\/b><span style=\"font-weight: 400;\">Ans: It happens when the issuing bank successfully processes a debit, but the confirmation doesn&#8217;t reach the gateway before the timeout window closes, usually due to network latency or <\/span><b>bank server downtime<\/b><span style=\"font-weight: 400;\">.<\/span><\/p>\n<p><b>#2 What&#8217;s the difference between a payment timeout and a late authorisation?<\/b><b><br \/>\n<\/b><span style=\"font-weight: 400;\">Ans: A timeout is an unconfirmed state caused by a missing response. A <\/span>late authorisation<span style=\"font-weight: 400;\"> is what happens when that response eventually arrives and confirms the transaction succeeded.<\/span><\/p>\n<p><b>#3 Should merchants auto-capture or auto-refund late-authorized payments?<\/b><b><br \/>\n<\/b><span style=\"font-weight: 400;\">Ans: It depends on the business model. Time-sensitive categories like food delivery or ticketing should default to refund; SaaS and low-inventory-risk categories can generally auto-capture using their <\/span>payment capture settings<span style=\"font-weight: 400;\">.<\/span><\/p>\n<p><b>#4 How can merchants avoid double-charging customers who retry after a timeout?<\/b><b><br \/>\n<\/b><span style=\"font-weight: 400;\">Ans: Use an <\/span>idempotency key<span style=\"font-weight: 400;\"> tied to a unique order ID on every payment request, so a retried attempt can&#8217;t create a duplicate charge if the original payment later succeeds.<\/span><\/p>\n<p><b>#5 Why shouldn&#8217;t merchants rely on browser redirects to confirm payment status?<\/b><b><br \/>\n<\/b><span style=\"font-weight: 400;\">Ans: A redirect only reflects the customer&#8217;s session state, not the actual bank confirmation. If the customer closes the tab, the redirect never fires, even if the payment succeeds. The <\/span>payment authorized webhook<span style=\"font-weight: 400;\"> and server-side status checks are the reliable source of truth.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Learn the difference between payment timeout and late authorisation, and how to handle late authorised payments with capture, refund, and webhook logic.<\/p>\n","protected":false},"author":151156511,"featured_media":19015,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1387],"tags":[3591],"class_list":{"0":"post-19014","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-payments","8":"tag-payment"},"_links":{"self":[{"href":"https:\/\/learn.razorpay.in\/learn\/wp-json\/wp\/v2\/posts\/19014","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/learn.razorpay.in\/learn\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/learn.razorpay.in\/learn\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/learn.razorpay.in\/learn\/wp-json\/wp\/v2\/users\/151156511"}],"replies":[{"embeddable":true,"href":"https:\/\/learn.razorpay.in\/learn\/wp-json\/wp\/v2\/comments?post=19014"}],"version-history":[{"count":1,"href":"https:\/\/learn.razorpay.in\/learn\/wp-json\/wp\/v2\/posts\/19014\/revisions"}],"predecessor-version":[{"id":19016,"href":"https:\/\/learn.razorpay.in\/learn\/wp-json\/wp\/v2\/posts\/19014\/revisions\/19016"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/learn.razorpay.in\/learn\/wp-json\/wp\/v2\/media\/19015"}],"wp:attachment":[{"href":"https:\/\/learn.razorpay.in\/learn\/wp-json\/wp\/v2\/media?parent=19014"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/learn.razorpay.in\/learn\/wp-json\/wp\/v2\/categories?post=19014"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/learn.razorpay.in\/learn\/wp-json\/wp\/v2\/tags?post=19014"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}