Processing choices

Taking deposits before the remaining order balance

Give the provider a timeline showing two intended collections against one purchase: what triggers the deposit, how its amount is determined, when the remaining balance is requested or charged, and what is supplied before and after each event. Include cancellation treatment and the customer’s agreement to any later merchant-initiated payment. Ask for confirmation of that exact model, product and integration. A deposit label, a saved payment method or permission to accept ordinary checkout payments does not establish support for both stages.

For: A research-only merchant considering a collected deposit followed by a separate payment for the remaining order balance.

Updated 2026-10-01

Discuss my processing options

Describe the two collections against the same purchase

Start with the underlying order and its agreed price or documented price basis. Record whether the deposit is a fixed amount or a stated portion, which event makes it due, and how it is credited against the purchase. Then identify what determines the remaining amount and when it becomes due. The provider should be able to see how both amounts relate to the same obligation without guessing from two unrelated payment descriptions.

Put the actual fulfillment milestones beside that schedule. State whether the first collection precedes stock availability, preparation or dispatch, and whether anything is supplied before the second collection. If the sequence is planned, label it planned. Existing order and payment records can establish what has happened; a proposed checkout screen cannot establish prior processing history.

Keep the provider, payment method, platform and extension named on this timeline. Support for a payment feature in one integration is not evidence that your installed extension exposes it or that another provider accepts the same collection model.

A collected deposit is different from an uncaptured hold

Use the payment record to distinguish money captured as the deposit from an amount only authorized. Do not count a hold toward the collected total. If the proposed design is to authorize the full purchase and capture only the deposit, it needs a specific capability check before anyone assumes the remaining amount will stay available.

Stripe’s authorization-and-capture documentation says a capture normally takes the authorized amount, while capturing less normally releases the remainder. Most payments allow only one capture; retaining and capturing the remainder requires supported multicapture. Those limits mean that a partial capture is not a general deposit-and-balance feature. The later balance cannot simply be presumed capturable from the original authorization.

The appropriate question is whether the provider and installed integration support the two actual collection events you described. Record the answer against that design. Do not replace an unsupported two-stage model with an assumed longer hold, larger capture or hidden additional charge.

Decide how the later payment is initiated

A buyer returning to pay a balance and the merchant initiating a later payment without the buyer present are different workflows. State which is intended. For a returning buyer, identify the actual approved payment request process. For a merchant-initiated collection, identify the agreement authorizing that specific future use and where its record is retained.

Stripe’s save-and-reuse guidance separates saving a method in setup mode from making a payment. Its future-use terms cover agreement to initiation, anticipated timing or frequency, and how the amount is determined. Usage must stay within the customer’s agreed scope, with explicit consent for offline charging or reuse for future purchases and a retained agreement record. The existence of a saved method alone answers none of those questions.

Compare the remaining-balance trigger with the wording the customer agrees to. A balance calculated later needs an amount basis; an undefined future charge is not made specific by calling it the remainder. Use this comparison to identify missing terms for review, not to draft legal consent language or authorize a payment from this article.

Show what happens if the order stops between stages

Record the actual cancellation policy separately for the period before the deposit, after it is collected, and after the balance. Identify what the business says about the deposit, any remaining payment request and goods already supplied. Do not infer that the word deposit makes it nonrefundable or that canceling fulfillment automatically cancels a payment request. Conflicts or silent terms remain questions for the responsible owner and, where legal interpretation is needed, qualified counsel.

Before launch, assemble the timeline, public offer and customer-agreement record location for the provider. Ask whether its response covers the actual products, collection method, interval, fulfillment timing and cancellation model. Stripe’s restricted-businesses policy prohibits processing for undisclosed products and misleading business information; its approvals are service-specific. That policy is separate from another provider’s decision and does not universally approve or reject research-only merchants.

Prism’s processing consultation can help organize the business description and the provider question. Send the website, research-only products and the unresolved stage of the proposed collection model. Scope, responsibilities, fees and terms are discussed before work. The inquiry receives email follow-up and is not a processing application, appointment or purchase.

Deposit and balance timeline

Fill this from the actual offer, agreements and authorized internal records. Put both planned stages in time order and label planned behavior clearly. A missing provider answer leaves support unconfirmed. Record document locations and non-sensitive summaries rather than copying customer or payment data.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

Deposit and balance timeline. The last column is for temporary notes.
Stage or conditionRecord to inspectDecision it supportsYour timeline
Underlying purchaseOrder terms and the agreed total or price basis, including the currency.Establish what both collections pay for and how the first amount reduces the balance.
Deposit triggerOffer terms, proposed collection event and any existing capture record.Distinguish a planned amount, an authorization and a genuinely collected deposit.
Remaining payment triggerBalance calculation and the event that makes it due; state who initiates payment.Identify a customer-return payment separately from a merchant-initiated future charge.
Fulfillment milestoneActual availability, preparation and dispatch commitments beside both collection dates.Show what is supplied before each payment and what is still owed afterward.
Future-use agreementLocation and version of the retained agreement, timing and amount basis.Check that the contemplated later use is within consent; a saved method is not payment.
Cancellation treatmentThe applicable policy at each stage and the owner of unresolved interpretations.Separate deposit treatment, outstanding balance and fulfillment obligations.
Provider responseDated answer naming the business, two-stage model, payment method and integration.Record confirmed conditions and unanswered parts; ordinary checkout availability is insufficient.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.

Limits

  • This page does not establish that any provider or plugin supports deposits, multiple captures or later balance collection for the business.
  • Stripe’s capture and saved-method rules describe Stripe. Another payment rail requires its own documented support and terms.
  • Cancellation rights and enforceability require appropriate advice. Keep card numbers, authentication codes, tokens, bank details and customer records out of worksheets and the public form.

Related guides

Sources

  • Stripe authorization and capture: partial capture boundary — checked 2026-09-29. Capturing less than the authorized amount normally releases the remainder. Most payments permit one capture; retaining and capturing the remainder requires supported multicapture. This does not establish a deposit feature or account eligibility.
  • Stripe prohibited and restricted businesses — checked 2026-09-28. Stripe prohibits misleading business information and processing for undisclosed products. Approvals are service-specific and can be modified or revoked; the policy is not another provider’s eligibility decision.
  • Stripe save a payment method without payment — checked 2026-09-29. Setup saves a method separately from charging. Future use is limited to agreed scope, requires specific consent and a retained record, and offline terms identify initiation, timing or frequency and the amount basis.
  • Prism solutions — checked 2026-09-21. Prism offers processing preparation and storefront review within an agreed scope, with fees and terms discussed before work. Provider eligibility and account terms stay with the provider.
  • Prism contact — checked 2026-09-21. The form asks for website, products and question, excluding payment-card details, passwords and customer records. Email follow-up is not an appointment, purchase or processing application.

Discuss my processing options

Want to talk through your own processing situation?

Discuss my processing optionsAll resources