Separate the approved amount from the purchase obligation
Source facts: Stripe describes partial authorization as requesting approval for part of a card transaction when the available balance cannot cover the originally requested amount; the customer can then use an alternative payment method for the remaining balance.[1] Before using it, Stripe tells businesses to decide whether to create a separate PaymentIntent for another payment method, cancel the entire PaymentIntent, or capture only up to the partially authorized amount.[1] Editorial recommendation: treat those as three distinct commercial decisions, not interchangeable technical success paths. An approval below the order total should open a remainder decision rather than automatically mark the whole purchase paid. Keep the agreed order amount, authorized amount, collected amount and unresolved balance separately visible to operations. Assign an owner to the unresolved balance and tell the customer which choice is available. This article concerns insufficient authorized amounts and split tender, not capture deadlines; it describes Stripe documentation, not a PayIn capability.
Check eligibility before promising a second-payment journey
Source facts: the cited documentation places access on Stripe IC+ pricing and says to contact sales or support to enable the feature.[1] It limits partial authorization to online card payments, names Visa, Mastercard, Discover and Amex as supporting networks, and says support depends on issuer and card type.[1] Stripe also makes the business responsible for applicable laws, regulations and network rules.[1] Editorial recommendation: confirm eligibility for the actual account, transaction type and card population before advertising split tender. Do not turn the network list into a guarantee that every customer can obtain a smaller approval. The page's network-rule examples are explicitly framed as of May 2024; they should not be represented as independently verified current rules.[1] Ask the responsible payments or compliance team to check current requirements. Define an ordinary payment-failure alternative for customers whose transactions do not qualify, without implying that opting in forces an issuer to grant partial approval.
Read the authorization result before calculating the remainder
Source facts: Stripe enables the request with request_partial_authorization set to if_available and illustrates a manual-capture flow.[1] Its confirmation response exposes partial_authorization.status as partially_authorized, fully_authorized, declined or not_requested, together with amount_requested and amount_authorized under the card payment details of latest_charge.[1] Stripe recommends manual capture because it allows evaluation of the approved amount before collection; automatic capture can collect an insufficient amount.[1] Editorial recommendation: branch on the actual response and compare monetary amounts, rather than treating the request setting as evidence that partial authorization occurred. Retain the original order total independently of a payment object's changing amount. For a partially authorized result, calculate the intended remainder from the agreed purchase amount and the portion allocated to the first payment, using consistent currency units. Keep that planned allocation distinct from money actually received. Route missing, inconsistent or unexpected response data to reconciliation instead of guessing what the customer owes.
Numerical illustration: decide what happens to the missing amount
Illustration only, not an executed test or a forecast: suppose an unchanged order costs 120 dollars and the first card authorizes 75 dollars. The uncovered portion is 45 dollars. Editorial recommendation: if the customer wants the full order, explain that the first portion is authorized rather than necessarily collected, and ask them to pay the remaining 45 dollars through the approved second-payment journey. Stripe's documented option is a separate PaymentIntent for another payment method.[1] Link both attempts to the same order in the merchant's records, and avoid requesting the full 120 dollars again while the first allocation remains active. If the customer declines the second payment, offer cancellation or an explicitly agreed smaller purchase. A 75-dollar purchase is a different commercial outcome, not a fully paid 120-dollar order. If only 75 dollars is ultimately collected against the unchanged order, the remaining 45 dollars is still unresolved. These amounts and order-handling choices are editorial examples, not a statement of issuer approval ratios or Stripe-managed order accounting.
Give each remainder choice a clear completion condition
Source facts: Stripe permits capture up to the amount or amount_capturable returned in the confirmation response, and network restrictions prohibit overcapture on a partially authorized transaction.[1] Stripe also asks businesses to communicate clearly with customers about how they proceed and any potential impact.[1] Editorial recommendation: define completion at the order level. For split tender, require evidence that both payment portions meet the merchant's collection and fulfillment policy; creating the second PaymentIntent alone should not release the order. For a smaller purchase, obtain agreement to the revised items, price and fulfillment scope before treating the reduced collection as sufficient. For cancellation, record which payment attempts still need resolution and present the customer with an accurate status. Do not promise an exact bank hold-release time that this source does not establish. Never use a larger capture on the first card as an improvised way to eliminate the remainder. Have support explain the chosen purchase outcome as well as the payment outcome.
Handle failure across both payment portions
Source facts: the cited guide says an issuer decline returns card_declined, and Stripe declines a partially authorized PaymentIntent below its minimum charge amount.[1] In its automatic-capture example, a payment can be succeeded after only the partially authorized amount has been collected.[1] Editorial recommendation: keep a failed or abandoned remainder payment separate from completion of the first portion. If the second payment is declined, offer an explicit retry or cancellation choice and preserve the unpaid amount. If the customer leaves, retain an unresolved order state rather than silently fulfilling. If the first portion has already been collected and the purchase is cancelled, identify that collected money for the appropriate refund workflow instead of assuming cancellation of an authorization undoes a completed collection. If the second portion succeeds but collection of the first fails, stop fulfillment and reconcile both records before asking for more money. Handle duplicate submissions and uncertain responses by inspecting existing attempts before creating replacements. These are proposed operational safeguards; the source does not specify an atomic, all-or-nothing split-tender transaction.
Acceptance checklist for an amount-aware release
Editorial acceptance checklist, not completed testing: first, confirm account eligibility and document the permitted transaction scope. Second, demonstrate distinct handling of fully_authorized, partially_authorized, declined and not_requested responses, including a below-minimum failure. Third, use a labelled numerical scenario to show that an unchanged order remains incomplete when collected funds are below its total. Fourth, verify that a remainder attempt requests only the intended balance and is linked to the original order. Fifth, review abandonment, duplicate submission, second-payment failure and one-portion-only collection with an assigned recovery owner. Sixth, inspect the customer messages for authorization versus collection, reduced-purchase consent and cancellation status. Seventh, reconcile all payment portions before declaring the order ready for fulfillment, and verify that no path attempts prohibited overcapture. Stripe provides a partial-authorization test payment method, pm_card_debit_partialAuthorization, whose documented behavior approves 70% of the requested amount, rounded down to the nearest unit, when partial authorization is requested.[1] That is source-described test behavior, not evidence that these checks were run. Editorial review date: 2026-09-21. The supplied source does not establish a publication date or the current eligibility of any particular merchant account.
Sources and dates
Verified on 2026-09-21. Source dates distinguish explicitly stated publication and update dates; an unspecified date does not mean the source was published today. This is public-document research, not a live payment test, security audit or accessibility certification. Vendor facts apply to the cited vendor; proposed workflows are editorial synthesis.
More new articles
Recover ACH microdeposit verification without wasting the next attempt →
A valid tax ID is not customer identity verification or a tax decision →
All field guides →