A card authorization is not the same as a captured payment, and neither is a production instruction. For a company store that requires payment before decoration begins, release the order only after the required payment has succeeded, the current merchandise specification is approved and the supplier can accept it. If the program intentionally uses another funding arrangement, document that exception instead of treating a pending card hold as cash collected.
The difficult decision is timing: should a store capture at checkout, after a short review or at fulfillment? A payment setting that works for stocked products can create a deadlock for made-to-order apparel. This guide helps program owners and implementation teams connect the payment clock to the production clock without confusing the two.
Publisher perspective: Brand Sauce publishes this guide as a company-store provider. The operating recommendations are a proposed design, not a statement that Brand Sauce uses Stripe or Shopify or includes these payment controls. Official documentation was checked October 18, 2026. Confirm the actual provider, payment methods, country support and implementation scope for your store.
Separate the request, payment and production states
An employee can finish selecting a jacket before every condition for making it has been met. Maintain three separate records: what was requested, how it is funded and whether the supplier has accepted production. A single green “complete” label is not enough to explain all three.
| Event | What it establishes | What it does not establish |
|---|---|---|
| Order submitted | A merchandise request exists | Payment succeeded or stock was reserved |
| Card authorized | A payment hold exists under the processor's rules | The payment has been captured |
| Payment succeeded | The payment flow reached its successful state | The artwork is approved or production has started |
| Supplier release acknowledged | The receiving production system accepted the specified order | The item has shipped |
Stripe's payment lifecycle documentation distinguishes requires_action, processing, requires_capture and succeeded. It also distinguishes a successful SetupIntent, which prepares a payment method for future use, from a successful PaymentIntent, which completes a payment flow. Saving a card is therefore not evidence that an order was paid.
Use the payment provider's actual status definitions rather than translating every intermediate state into “paid.” At the program level, show a clear next action: recipient authentication needed, payment processing, review pending or ready for release. Avoid telling an employee to order again simply because one of these steps is unfinished.
Choose capture timing around the real handoff
Start with the supplier's requirement: what must be true before the order enters decoration or picking? Then choose a supported collection policy. The following is a decision framework, not a universal recommendation about when merchants may charge customers.
| Approach | Useful when | Tradeoff to resolve |
|---|---|---|
| Capture at checkout | Order details are final and the supply route is ready | A later inability to fulfill creates a refund or revision task |
| Authorize, then capture after review | A short, bounded review must happen before commitment | The review must finish within the actual authorization window |
| Capture at fulfillment | The fulfillment workflow supports it and the timing fits | Production may require payment before fulfillment can occur |
| Separate agreed business funding | The employer purchases under accepted commercial terms | The supplier must accept that route; an employee allowance is not proof of payment |
Shopify provides a concrete compatibility warning: its capture-at-fulfillment documentation says that option is incompatible with fulfillment apps that need a paid order before starting. Its entire-order option also does not capture partially fulfilled orders. These are Shopify-specific behaviors, but they reveal a question every buyer should ask: can the configured trigger actually occur before collection is required?
Ask the provider to draw the exact sequence. “The platform handles payment” is not a sufficient answer if the decorator, storefront and employer each expect another party to act first. Identify one owner of capture and one owner of production release. They may be the same team, but they are different responsibilities.
Use our purchase-order versus card-payment guide to choose the funding route. The narrower decision here is how a card-funded order moves from authorization to collection without accidentally becoming an unfunded production job.
Treat authorization expiry as a deadline, not a reminder
Stripe's authorization and capture guidance says that holds expire; uncaptured funds are released and the payment becomes canceled. For card charges, its capture_before field identifies the expiry. Windows depend on transaction conditions. Do not build a program around an assumed universal seven-day hold.
Our recommended operating record includes the order revision, payment reference, authorized amount and currency, actual expiry, review owner and planned next action. Use a named time zone in operator views. Escalate early enough for a real decision; an alert after the deadline cannot preserve the original authorization.
A long review is a reason to reconsider the flow, not a reason to pretend a hold can last indefinitely. Ask whether specifications should be approved before the payment step, whether a supported later-payment process is appropriate or whether the employer should use an agreed business purchasing route. Any later collection must follow the provider's supported consent and authentication process.
Do not capture automatically merely to keep an unresolved order alive. Collection must match the communicated terms and approved commercial policy. Equally, do not leave the supplier waiting on an expired authorization while the employee sees an apparently active order. Give that exception an owner and a visible resolution path.
Split shipments do not automatically mean split captures
A mixed cart might contain a stocked bottle and a jacket that needs embroidery. Decide whether its payment is collected once for the whole accepted order or through a supported staged process. Do not let shipping updates invent the payment policy after checkout.
Stripe notes that most payments permit only one capture: a partial capture releases the remainder, and further capture is not generally available unless the payment supports multicapture. Shopify's per-fulfillment capture option has plan and payment-provider requirements. Confirm the exact combination before offering a staged-charge experience; a feature name alone does not establish support for your account.
For each order type, record how merchandise, delivery charges and any employee contribution are allocated. If a line is removed, the revised amount needs a deliberate reconciliation. Keep the original order reference and the revised specification together so a payment correction cannot be mistaken for a second purchase.
For a fully employer-funded gift with no employee payment, do not manufacture a card step merely to reuse a familiar workflow. Verify the employer funding route instead. For a paid upgrade, the contribution and employer funding both need their own accepted status before the combined order qualifies for release.
Use verified payment state, not the thank-you page
Stripe's Checkout fulfillment guidance explains that customers may pay and lose their connection before reaching the return page. It calls for server-side payment-event handling, checking payment status and ensuring repeated calls do not fulfill the same payment twice. Delayed payment methods can finish after checkout itself completes.
For a company store, require the implementation team to demonstrate the equivalent behavior in its supported stack. A recipient refreshing the confirmation screen must not create another jacket. A payment event arriving twice must not create two release instructions. The system should verify that the payment belongs to the correct order revision, amount and currency before considering that order funded.
If collection succeeds but supplier release is unresolved, investigate the existing release reference before retrying. Do not ask the employee to pay again to repair an uncertain production handoff. Our order-sync recovery guide covers that separate boundary in detail.
Illustrative example: the jacket that cannot start
Imagine a store configured to capture only after fulfillment. Its embroidery partner accepts work only after payment, and the quoted production timeline extends beyond the card authorization's actual expiry. This is an illustrative design problem, not a Brand Sauce client incident or measured result.
The order has two problems: neither side can trigger the next step, and the payment hold has a deadline. Sending an “urgent” note to production fixes neither. The program team needs to select a supported collection point that precedes the required production commitment, or negotiate a different accepted funding route. The employee-facing terms must describe that choice accurately.
Bulk is not exempt. A preordered event batch can have an even longer gap between selection and shipment. A hybrid program may use one funding arrangement for purchased stock and another for individually decorated replenishment. Keep those order types identifiable; do not assume an on-demand model is always cheaper or that one capture setting fits every stream.
A six-case payment-to-production acceptance card
Before launch, ask for these demonstrations in a test environment without creating live charges or manufacturing commitments. Retain the order references, observed payment states and release outcomes.
- Authorized only: an order needing captured payment stays out of production while its payment remains uncaptured.
- Short review completed: the approved current revision proceeds through the intended collection and release steps exactly once.
- Expiry during review: an outdated hold cannot silently qualify as accepted funding; a named operator receives the exception.
- Split fulfillment: one item shipping does not cause an unintended charge or leave the remaining line without its required funding.
- Interrupted browser and repeated event: closing the return page does not lose a successful payment, and a repeated notification does not duplicate production.
- Paid but release unresolved: support investigates the existing supplier handoff without starting another payment.
Label each result supported, manual or unresolved. A controlled manual process can be appropriate for a small program, but it still needs an owner, backup and exception list. Record implementation and operating charges as quote-needed where unknown, rather than assuming automation is included.
Frequently asked questions
Does an order confirmation mean the card was charged?
Not necessarily. An order receipt, an authorization and a successful collected payment can represent different events. Ask support to check the payment record, not infer collection from the email subject line.
Should all company stores capture at checkout?
No. A short review, fulfillment policy or agreed business funding arrangement may justify another route. Choose the timing that the actual payment and production systems support, and explain it before the recipient places the order.
Can a cancellation request simply erase the payment?
Resolve payment and production separately. Determine whether the payment is uncaptured or already collected, and whether the supplier can stop work. Follow the supported cancellation or refund process; a payment action does not itself stop embroidery. See our order-change and cancellation guide.
The launch requirement is a demonstrated sequence: accepted funding, approved specification and one acknowledged production release. Ask your proposed company-store provider to show that sequence—including the failed and delayed cases—before selecting a capture setting.
Hero: AI-generated conceptual illustration, not a payment interface or production facility.
