{"id":28379,"date":"2026-11-13T17:19:41","date_gmt":"2026-11-13T11:49:41","guid":{"rendered":"https:\/\/razorpay.com\/blog\/?p=28379"},"modified":"2026-11-13T17:19:41","modified_gmt":"2026-11-13T11:49:41","slug":"travel-booking-payments-razorpay","status":"publish","type":"post","link":"https:\/\/razorpay.com\/blog\/travel-booking-payments-razorpay\/","title":{"rendered":"Travel Booking Payments With Razorpay: Authorisation, Capture and Cancellation Workflows"},"content":{"rendered":"<p>Travel booking payments connect a reservation decision with a payment decision: authorisation places the payment in the authorised state, capture moves it into the captured state, and cancellation requires a different action depending on whether capture has already happened. With Razorpay, a booking team can use documented manual capture settings for eligible Orders API payments while it confirms availability with a supplier.<\/p>\n<p>The confirmation process has to fit the configured capture timeout, and authorised payments must be captured within three days of payment creation. A booking for travel months from now does not extend that deadline. If the reservation cannot be confirmed in time, stop the capture path and track the applicable auto-refund. If the payment was already captured, process the cancellation through the refund workflow instead.<\/p>\n<div style=\"border-left: 4px solid #007BFF; background: #f0f8ff; padding: 25px; margin: 30px 0; font-family: Arial, sans-serif; text-align: left;\">\n<h2 style=\"margin-top: 0; color: #007bff; font-size: 22px;\">Key Takeaways<\/h2>\n<ul style=\"margin: 15px 0; padding-left: 20px; color: #333; line-height: 1.6;\">\n<li>Razorpay&#8217;s documented manual capture settings can support a short booking-confirmation workflow for eligible Orders API payments.<\/li>\n<li>Plan from payment creation and the configured timeout, with a three-day outer capture boundary.<\/li>\n<li>International cards require separate enablement, completed KYC and banking-partner approval.<\/li>\n<li>Cancellation before capture and refund after capture require different actions and records.<\/li>\n<li>A partial refund does not turn the payment&#8217;s top-level status into refunded until the full amount is refunded.<\/li>\n<li>Capture does not establish settlement to your bank or payment to a supplier.<\/li>\n<li>Longer hotel-security holds and incremental authorisation need separately verified product support.<\/li>\n<\/ul>\n<\/div>\n<h2>Can Razorpay Authorise a Travel Booking Payment Before Capture?<\/h2>\n<p>Razorpay documents manual capture for eligible payments created using the Orders API. A travel business can align capture with a short booking-confirmation process, provided the payment is authorised and captured before its configured timeout and within three days of payment creation. Confirm your account&#8217;s settlement model and payment method before offering this flow.<\/p>\n<h3>Separate the Booking State From the Payment State<\/h3>\n<p>Your reservation system&#8217;s labels are not Razorpay API states. Keep them in separate columns of the same ledger.<\/p>\n<div class=\"rzp-travel-table\" style=\"overflow-x: auto; -webkit-overflow-scrolling: touch; margin: 20px 0;\" tabindex=\"0\" role=\"region\" aria-label=\"Travel payment comparison table\">\n<table style=\"width: 100%; min-width: 620px; border-collapse: collapse;\">\n<thead>\n<tr>\n<th scope=\"col\">Record<\/th>\n<th scope=\"col\">What it means<\/th>\n<th scope=\"col\">What it does not establish<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Booking pending<\/td>\n<td>The merchant is checking inventory or supplier confirmation.<\/td>\n<td>Successful capture or a confirmed reservation.<\/td>\n<\/tr>\n<tr>\n<td>Payment authorized<\/td>\n<td>The payment is in the state eligible for capture.<\/td>\n<td>A captured payment, bank settlement or an unlimited funds reservation.<\/td>\n<\/tr>\n<tr>\n<td>Payment captured<\/td>\n<td>Capture has completed for the payment.<\/td>\n<td>Supplier fulfilment, bank settlement or completion of a later refund.<\/td>\n<\/tr>\n<tr>\n<td>Booking cancelled<\/td>\n<td>The merchant has cancelled the reservation.<\/td>\n<td>That the payment or refund has changed automatically.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h3>Configure the Capture Clock Before Taking a Booking<\/h3>\n<p>Payments are auto-captured by default. To use this manual-capture workflow, the account owner must configure the <a href=\"https:\/\/razorpay.com\/docs\/payments\/payments\/capture-settings?preferred-country=IN\">payment capture settings<\/a>. Manual timeouts can range from 12 minutes to three days. Capture authorised payments before the configured timeout and within three days of payment creation; otherwise, they are automatically refunded. The deadline starts at creation, not at the travel date or a late authorisation event.<\/p>\n<p>Scope matters. For Direct Settlement merchants, payments are <a href=\"https:\/\/razorpay.com\/docs\/payments\/payments\/capture-settings?preferred-country=IN\">auto-captured irrespective of the configuration<\/a>, and bank transfers do not support manual capture. Confirm support for the exact card and integration before launch.<\/p>\n<p><strong>Did you know?<\/strong> Capture options sent through the <a href=\"https:\/\/razorpay.com\/docs\/payments\/payments\/capture-settings\/api?preferred-country=IN\">Orders API take precedence<\/a> over the account-level settings configured on the Dashboard.<\/p>\n<h3>Match the Payment Flow to the Confirmation Time<\/h3>\n<p>This flow suits bookings you can confirm before the configured capture deadline. A longer hotel-incidentals hold or an increase to an existing authorisation requires separately verified support for the exact integration. The standard capture settings alone do not establish either capability.<\/p>\n<p><strong>Pro tip:<\/strong> Choose an internal confirmation deadline earlier than the payment timeout. Store the creation timestamp, the configured deadline and the booking decision together so operations can act before expiry.<\/p>\n<h2>How Do International Cards and High-Value Travel Bookings Work?<\/h2>\n<p>Razorpay supports accepting foreign-bank cards once international payments are enabled for an eligible account. Start with an active account and completed KYC, publish the required website policies, then request International cards activation from the Dashboard. Banking-partner approval and risk checks still apply. Verify the booking amount and the capture flow separately.<\/p>\n<h3>Request International-Card Activation for the Actual Business Model<\/h3>\n<p>The documented path runs through Account and Settings, then International payments under Payment methods, then Activate, followed by the requested information. Eligibility requires an active account with KYC completed and a website carrying clearly defined terms and conditions, privacy, refund and cancellation, and shipping policy sections. Razorpay states that <a href=\"https:\/\/razorpay.com\/docs\/payments\/international-payments\/international-debit-credit-cards?preferred-country=IN\">international payments cannot be enabled without these sections<\/a>, that special security and risk checks apply, and that the feature is enabled only after banking partners approve it. Razorpay also supports <a href=\"https:\/\/razorpay.com\/docs\/payments\/international-payments?preferred-country=IN\">3D Secure 2.0 for international cards<\/a>.<\/p>\n<p>Make those policies specific to your travel service and confirm how the documented website requirements apply to your business. Activation of each payment method involves <a href=\"https:\/\/razorpay.com\/docs\/payments\/dashboard\/account-settings\/payment-methods?preferred-country=IN\">onboarding with partner banks<\/a>. Use the approved international-card collection flow for the booking you sell. That enablement does not by itself authorise outbound supplier payments, every settlement currency or card network, or a hotel-security hold.<\/p>\n<h3>Check the Booking Amount Before Offering the Payment Option<\/h3>\n<p>High-value travel packages sit across three separate limit layers. The published method limit lists <a href=\"https:\/\/razorpay.com\/docs\/payments\/payment-methods\/transaction-limits?preferred-country=IN\">Rs 5,00,000 for cards and netbanking<\/a>, subject to banking-partner restrictions, with a limit-increase request available through support. Your account also carries configurable domestic and international transaction limits in the <a href=\"https:\/\/razorpay.com\/docs\/payments\/dashboard\/account-settings\/transaction-limits?preferred-country=IN\">Dashboard<\/a>, where the maximum depends on business category. Finally, the customer&#8217;s issuer applies its own card limit.<\/p>\n<p>Confirm all three before advertising a high-value payment option, and do not split a transaction to work around a limit. Once eligibility is settled, you can <a href=\"https:\/\/razorpay.com\/accept-international-payments\/\">accept international payments<\/a> for the approved use case.<\/p>\n<h2>What Happens When a Booking Is Cancelled Before or After Capture?<\/h2>\n<p>Read the payment&#8217;s current state before handling a cancelled booking. If an eligible manual-capture payment is still authorised, stop the capture job and track its configured auto-refund path. If capture has completed, initiate a full or partial refund under the disclosed cancellation policy. Cancelling the reservation alone performs neither payment action.<\/p>\n<h3>Cancellation Before Capture<\/h3>\n<p>Stop your application&#8217;s planned capture and re-fetch the payment state before acting, because a capture may already be in flight or an order-level setting may override the Dashboard configuration. Payments not captured within the timeout are <a href=\"https:\/\/razorpay.com\/docs\/payments\/refunds\/auto-refunds?preferred-country=IN\">auto-refunded<\/a> and processed at normal speed. Do not promise immediate issuer release. Use the documented return path and verify any alternative early-release action for your integration.<\/p>\n<h3>Cancellation After Capture<\/h3>\n<p>Refunds initiated through the Dashboard or API require a captured payment. You can <a href=\"https:\/\/razorpay.com\/docs\/payments\/refunds\/issue?preferred-country=IN\">issue multiple partial refunds<\/a> as long as their sum does not exceed the captured amount, and the payment moves to refunded only when the entire amount is refunded. Normal refunds are <a href=\"https:\/\/razorpay.com\/docs\/payments\/refunds?preferred-country=IN\">not possible for a payment more than six months old<\/a>, which matters when travel is paid for far in advance. A payment under an active dispute <a href=\"https:\/\/razorpay.com\/docs\/api\/refunds\/create-normal?preferred-country=IN\">cannot be refunded<\/a> until the dispute is resolved.<\/p>\n<div class=\"rzp-travel-table\" style=\"overflow-x: auto; -webkit-overflow-scrolling: touch; margin: 20px 0;\" tabindex=\"0\" role=\"region\" aria-label=\"Travel payment comparison table\">\n<table style=\"width: 100%; min-width: 620px; border-collapse: collapse;\">\n<thead>\n<tr>\n<th scope=\"col\">Situation<\/th>\n<th scope=\"col\">Merchant action<\/th>\n<th scope=\"col\">Customer communication<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Still authorised, booking rejected<\/td>\n<td>Stop capture and monitor the configured auto-refund and final records.<\/td>\n<td>Explain the booking cancellation and the tracked payment-return process; do not promise instant release.<\/td>\n<\/tr>\n<tr>\n<td>Captured, booking fully cancelled<\/td>\n<td>Create the policy-based full refund and retain its ID.<\/td>\n<td>Give amount, original payment source, refund reference and the applicable tracked timeline.<\/td>\n<\/tr>\n<tr>\n<td>Captured, one component cancelled<\/td>\n<td>Calculate the disclosed refundable amount and issue an eligible partial refund.<\/td>\n<td>Explain the refund and the remaining booking separately.<\/td>\n<\/tr>\n<tr>\n<td>Capture or refund outcome uncertain<\/td>\n<td>Fetch current status and reconcile before repeating the action.<\/td>\n<td>Mark the case pending; do not tell the customer it is complete prematurely.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>For <a href=\"https:\/\/razorpay.com\/docs\/payments\/refunds\/normal?preferred-country=IN\">normal refunds<\/a> no additional refund processing fee is charged, but the original transaction fee and GST levied at capture are not reversed to the merchant. A post-capture cancellation is therefore not cost-free. Instant refunds carry <a href=\"https:\/\/razorpay.com\/docs\/payments\/refunds\/instant?preferred-country=IN\">separate fees<\/a> and can <a href=\"https:\/\/razorpay.com\/docs\/payments\/refunds\/instant?preferred-country=IN\">fall back to normal processing<\/a>.<\/p>\n<h2>A Worked Travel Booking Ledger From Reservation to Refund<\/h2>\n<p>All amounts, times and outcomes below are illustrative. They are not an actual transaction, a merchant result or a universal cancellation policy.<\/p>\n<p>Illustrative booking: a Rs 60,000 package is awaiting hotel confirmation. A confirmed merchant account has the proposed card and manual-capture flow with a configured 24-hour timeout, and capture must still satisfy the three-day creation boundary. The travel date is two months away and does not affect the payment deadline. Branches B and C are alternatives to branch A, not later events in the same booking.<\/p>\n<div class=\"rzp-travel-table\" style=\"overflow-x: auto; -webkit-overflow-scrolling: touch; margin: 20px 0;\" tabindex=\"0\" role=\"region\" aria-label=\"Travel payment comparison table\">\n<table style=\"width: 100%; min-width: 620px; border-collapse: collapse;\">\n<thead>\n<tr>\n<th scope=\"col\">Example branch<\/th>\n<th scope=\"col\">Reservation record<\/th>\n<th scope=\"col\">Payment or refund record<\/th>\n<th scope=\"col\">Finance interpretation<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>A: 09:00, payment created and then authorised<\/td>\n<td>Supplier confirmation pending<\/td>\n<td>Payment ID and order ID; Rs 60,000 authorised; configured deadline next day 09:00<\/td>\n<td>No captured payment or bank settlement recorded yet.<\/td>\n<\/tr>\n<tr>\n<td>A: 09:30, supplier confirms<\/td>\n<td>Booking confirmed with supplier reference<\/td>\n<td>Fetch state; capture the matching Rs 60,000 before the deadline; verify the captured result<\/td>\n<td>Record the captured amount; reconcile bank settlement separately.<\/td>\n<\/tr>\n<tr>\n<td>A: later, one refundable Rs 15,000 activity cancelled<\/td>\n<td>Main trip confirmed; activity cancelled<\/td>\n<td>Issue one eligible Rs 15,000 partial refund; retain the refund ID and cumulative refunded amount<\/td>\n<td>Gross capture Rs 60,000; refunded Rs 15,000; principal retained Rs 45,000. Fees reconciled separately.<\/td>\n<\/tr>\n<tr>\n<td>B: alternative outcome, supplier rejects at 09:30<\/td>\n<td>Booking cancelled before capture<\/td>\n<td>Stop capture; check for an in-flight state change; track the documented auto-refund if still authorised<\/td>\n<td>Do not book the amount as captured revenue; record the final payment-return outcome.<\/td>\n<\/tr>\n<tr>\n<td>C: confirmation arrives after the timeout<\/td>\n<td>Booking confirmation needs a new customer payment decision<\/td>\n<td>Re-fetch state; do not attempt to capture an expired or already refunded payment<\/td>\n<td>Do not treat late supplier confirmation as settled funds; seek a fresh agreed payment flow.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>The same booking ID should connect the supplier reference, order ID, payment ID, creation time, capture deadline, capture result and refund IDs in the merchant ledger. Those links let support explain a cancellation without confusing a pending authorisation, a completed capture, a partial refund and a bank settlement.<\/p>\n<p><strong>Did you know?<\/strong> After a partial refund, the payment can remain in captured status. The refunded amount and the refund records are what tell you the remaining balance.<\/p>\n<h2>How to Build the Booking Confirmation and Capture Workflow<\/h2>\n<p>Design the merchant workflow around a shared booking and payment reference, verified payment status and a capture deadline. Confirm the reservation while capture remains eligible, then verify the result. For a failed or timed-out confirmation, prevent further capture attempts and reconcile any auto-refund. Treat retries and late events as state checks, not as permission to charge again.<\/p>\n<h3>The Eight-Step Implementation Checklist<\/h3>\n<ol>\n<li><strong>Confirm applicability.<\/strong> Have the account owner and an integration reviewer verify the payment method, settlement model, Orders API scope, international enablement and transaction limit. Record the exceptions, including Direct Settlement and bank transfers. Capture settings work only where the server side is <a href=\"https:\/\/razorpay.com\/docs\/payments\/payment-gateway\/web-integration\/standard\/integration-steps?preferred-country=IN\">integrated with the Orders API<\/a>.<\/li>\n<li><strong>Define the booking policy.<\/strong> Specify supplier-confirmation time, customer consent, cancellation cutoffs, refundable components and how an unavailable booking will be communicated. Keep the supplier&#8217;s inventory deadline separate from the payment deadline.<\/li>\n<li><strong>Create linked records.<\/strong> Create the order and a stable booking reference, then store the payment ID, amount, currency and creation timestamp. Keep API credentials server-side and out of logs.<\/li>\n<li><strong>Set the intended capture mode.<\/strong> Select the approved manual-capture configuration and a timeout that fits supplier confirmation. Verify order-level settings, which override the Dashboard. Add an internal warning before expiry.<\/li>\n<li><strong>Verify the payment result.<\/strong> Validate the checkout payment signature using the official integration guidance, then retrieve authoritative payment and order state through the <a href=\"https:\/\/razorpay.com\/docs\/api\/payments?preferred-country=IN\">Payments API<\/a>. Validate webhook signatures separately. A browser success screen is not evidence of capture.<\/li>\n<li><strong>Confirm or reject the reservation.<\/strong> On supplier confirmation, re-fetch the authorised payment, validate amount and currency, then <a href=\"https:\/\/razorpay.com\/docs\/api\/payments\/capture?preferred-country=IN\">capture the payment<\/a> through the supported API or the Dashboard. Operations teams can capture manually from Transactions, then Payments, then the Payment Id, then <a href=\"https:\/\/razorpay.com\/docs\/payments\/payments\/dashboard?preferred-country=IN\">Capture Payment<\/a>. On rejection, stop the capture job and follow the state-dependent cancellation route.<\/li>\n<li><strong>Handle duplicate and late events.<\/strong> Use application-level deduplication and guarded state transitions. <a href=\"https:\/\/razorpay.com\/docs\/payments\/payments\/late-authorisation?preferred-country=IN\">Late authorisation<\/a> happens when a bank status is not received at the time of payment, and Razorpay polls for three days from the payment creation day. A <code>payment.failed<\/code> webhook can be <a href=\"https:\/\/razorpay.com\/docs\/webhooks\/payments?preferred-country=IN\">followed by a payment.captured webhook<\/a> for the same transaction, so re-fetch current payment and booking state before deciding how to handle inventory or a retry. Late authorised payments that are not captured are <a href=\"https:\/\/razorpay.com\/docs\/payments\/payments\/late-authorisation\/handle?preferred-country=IN\">auto-refunded<\/a>.<\/li>\n<li><strong>Reconcile and communicate.<\/strong> Verify the final capture or refund records, reconcile settlements separately, and send the correct booking and payment update. Test rejected inventory, timeouts, duplicate events, uncertain capture responses, partial cancellations and international-card decline paths before launch.<\/li>\n<\/ol>\n<p>On the capture endpoint, the amount parameter is documented as the order amount in currency subunits, and the currency must match the payment. The worked example uses full capture. Do not infer arbitrary partial or repeated capture from the presence of an amount field. For refund retries, follow the <a href=\"https:\/\/razorpay.com\/docs\/api\/refunds\/normal-refunds-idempotent?preferred-country=IN\">documented idempotent refund flow<\/a>, which uses the <code>X-Refund-Idempotency<\/code> header with the same key and request body for a retry. Use a unique key for each distinct refund request. Do not assume that refund header is supported by the capture endpoint.<\/p>\n<p><strong>Pro tip:<\/strong> If a capture request times out, fetch the payment before retrying. The first request may have completed even though your application never received the response.<\/p>\n<h2>How Should Travel Teams Reconcile Cancellations, Refunds and Settlements?<\/h2>\n<p>Reconcile booking, payment, refund and settlement records separately. Compare captured principal against cumulative refunds, then reconcile fees, taxes and settlement adjustments. Keep the customer refund reference and the supplier cancellation reference together. An authorised payment or a submitted refund request does not establish that money has settled to the merchant or reached the customer.<\/p>\n<h3>Keep a Record for Each Stage<\/h3>\n<p>Store the booking ID, order ID, payment ID, supplier confirmation or cancellation reference, amount and currency, configured deadline, capture timestamp and result, refund ID and amount, cumulative refunds, latest status, and the applicable bank and settlement references when available. Not every identifier exists at every stage, so record which are pending rather than leaving blanks. Do not store unnecessary card data. These same fields map closely onto Razorpay&#8217;s <a href=\"https:\/\/razorpay.com\/docs\/api\/disputes\/entity?preferred-country=IN\">dispute evidence fields<\/a>, which include cancellation proof, refund confirmation, the refund and cancellation policy, customer communication and proof of service.<\/p>\n<h3>Give Customers a Status They Can Understand<\/h3>\n<p>Two illustrative messages: &#8220;Your booking was not confirmed. We have stopped the planned capture and are tracking the payment-return process. We will share the available refund reference and the applicable timeline.&#8221; And: &#8220;Your cancellation is confirmed. We have initiated a refund of Rs 15,000 to the original payment source. Your remaining booking value is Rs 45,000, subject to the disclosed cancellation terms.&#8221; Use the second only after the refund request is verified in the <a href=\"https:\/\/razorpay.com\/docs\/webhooks\/refunds?preferred-country=IN\">refund records<\/a>.<\/p>\n<p>Refund timing depends on the payment method, chosen refund speed and banking processing. Give the customer the applicable timeline from verified refund details or support guidance, and update them if that expected date changes. Do not promise an immediate return for an uncaptured payment or one fixed refund time for every international card.<\/p>\n<h3>Budget for the Refund Path and Capture Fees<\/h3>\n<p>Normal refund documentation states the original transaction fee and GST are not returned after capture, while auto-refunds of uncaptured payments have different fee and settlement treatment. Avoid computing a total cost from a universal rate. Funds reaching a supplier are a separate flow needing their own design. Where you retain a cancellation charge, confirm GST treatment with your tax advisor against the <a href=\"https:\/\/cbic-gst.gov.in\/pdf\/cir-178-08-2022-cgst.pdf\" rel=\"nofollow noopener\" target=\"_blank\">CBIC circular on cancellation charges<\/a>. Settlement to your bank follows capture under the <a href=\"https:\/\/razorpay.com\/docs\/payments\/settlements?preferred-country=IN\">applicable settlement schedule<\/a>.<\/p>\n<p>For an <a href=\"https:\/\/razorpay.com\/docs\/payments\/refunds\/auto-refunds?preferred-country=IN\">auto-refund before capture<\/a>, the amount does not enter the merchant settlement and no processing fee is deducted from settlement for that auto-refund. For a captured booking, reconcile the original capture fee, GST and each refund separately. The customer principal retained in the worked ledger is not the same as the amount credited to your bank after fees and other adjustments.<\/p>\n<p><strong>Did you know?<\/strong> Auto-refund documentation distinguishes paths using the payment&#8217;s captured field: an auto-refunded payment was not captured. That lets finance separate uncaptured-payment returns from refunds on captured payments.<\/p>\n<h2>Which Payment Approach Fits Your Travel Booking Model?<\/h2>\n<p>Match the collection approach to the booking requirement rather than to a product preference, and preserve the eligibility checks in every row.<\/p>\n<div class=\"rzp-travel-table\" style=\"overflow-x: auto; -webkit-overflow-scrolling: touch; margin: 20px 0;\" tabindex=\"0\" role=\"region\" aria-label=\"Travel payment comparison table\">\n<table style=\"width: 100%; min-width: 620px; border-collapse: collapse;\">\n<thead>\n<tr>\n<th scope=\"col\">Booking requirement<\/th>\n<th scope=\"col\">Approach to assess<\/th>\n<th scope=\"col\">Essential check<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Live inventory confirmed immediately<\/td>\n<td>Approved checkout with the chosen capture behaviour<\/td>\n<td>Verify booking and payment ordering, plus failure handling.<\/td>\n<\/tr>\n<tr>\n<td>Short supplier-confirmation delay<\/td>\n<td>Eligible Orders API manual capture<\/td>\n<td>Confirm merchant and method scope, the timeout, and the full capture amount.<\/td>\n<\/tr>\n<tr>\n<td>Agreed deposit with balance payable later<\/td>\n<td>Separate agreed collection request, where supported<\/td>\n<td>A captured deposit is a payment; it does not remain an authorisation hold.<\/td>\n<\/tr>\n<tr>\n<td>Customer pays an approved invoice or balance through a link<\/td>\n<td><a href=\"https:\/\/razorpay.com\/payment-links\/\">Razorpay Payment Links<\/a><\/td>\n<td>Verify link and order behaviour separately; do not assume this guide&#8217;s manual-capture settings apply.<\/td>\n<\/tr>\n<tr>\n<td>Weeks-long hotel-security or incremental hold<\/td>\n<td>Separately verified capability and agreement<\/td>\n<td>Do not infer support from standard capture controls.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>For broader selection context across methods and business models, the wider <a href=\"https:\/\/razorpay.com\/blog\/payment-gateway-travel-business\/\">payment gateway for travel business<\/a> overview covers the comparison questions this workflow guide does not repeat.<\/p>\n<h2>Frequently Asked Questions<\/h2>\n<h3>How Long Can a Razorpay Booking Payment Remain Authorised Before Capture?<\/h3>\n<p>Follow the configured capture timeout and capture eligible authorised payments within three days of payment creation. A shorter configured timeout can apply. The trip date or hotel check-in date does not extend this window. Confirm the account, payment method and integration before offering delayed capture, including any order-level override of Dashboard settings.<\/p>\n<h3>Does Cancelling a Booking Automatically Refund the Payment?<\/h3>\n<p>Cancelling the reservation does not by itself change the payment. Read the current payment state. If it is still authorised under the supported manual-capture flow, stop the capture job and track its configured auto-refund path. If it is captured, initiate the full or partial refund required by your cancellation policy and verify the refund record.<\/p>\n<h3>Can an Indian Travel Business Accept International Cards With Razorpay?<\/h3>\n<p>Eligible businesses can request international-card activation after completing KYC on an active account and meeting the required website-policy conditions. Apply through International payments in the Dashboard and provide the requested information. Banking-partner approval and risk checks apply. Separately verify transaction limits and the intended capture workflow for your booking model.<\/p>\n<h3>Can a Travel Operator Refund Only One Part of a Captured Booking?<\/h3>\n<p>Razorpay documents partial refunds on captured payments. Calculate the refundable component under the disclosed policy, issue the eligible refund and retain the refund ID. Multiple partial refunds must not exceed the captured amount. The payment can remain captured until fully refunded, so reconcile cumulative refund amounts rather than only the top-level status.<\/p>\n<h3>Are a Booking Hold, a Captured Deposit and Settlement the Same Thing?<\/h3>\n<p>They represent different stages. A booking hold reserves inventory in the merchant&#8217;s system. An authorised payment is eligible for capture within its supported window. A captured deposit is an actual payment and may need a refund if cancelled. Settlement concerns captured funds reaching the merchant&#8217;s bank under the applicable schedule. None alone confirms supplier fulfilment.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Plan travel booking payments with Razorpay. Understand authorisation, capture deadlines, international card approval and cancellation or refund workflows.<\/p>\n","protected":false},"author":180,"featured_media":28386,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[906],"tags":[],"class_list":{"0":"post-28379","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-payment-gateway"},"_links":{"self":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts\/28379","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/users\/180"}],"replies":[{"embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/comments?post=28379"}],"version-history":[{"count":2,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts\/28379\/revisions"}],"predecessor-version":[{"id":28384,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts\/28379\/revisions\/28384"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/media\/28386"}],"wp:attachment":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/media?parent=28379"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/categories?post=28379"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/tags?post=28379"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}