# Charge now or authorize first Whether to take the money in the same request as the approval, or hold the funds and capture them when you deliver. 2 questions, 4 outcomes ## When do you deliver what the customer paid for? https://devportal.qa.winkpg.io/docs/decide/charge-now-or-authorize-first/when-you-deliver.md Delivery is what decides this, not the product. Take the money when you've earned it, and hold it until then. **Choose one** - At the moment they pay. A download, a ticket, a counter sale, or a service already provided. Leads to: Send a sale. - Within a few days of the order. Goods you pick and ship, or a booking that starts this week. Leads to: Can the final amount change before you deliver?. - Weeks later, or on a date nobody knows yet. A preorder, a made-to-order item, or a charge after a stay ends. Leads to: Store the payment method and charge it at delivery. ### Send a sale https://devportal.qa.winkpg.io/docs/decide/charge-now-or-authorize-first/send-a-sale.md One request authorizes the payment and captures it, and the payment joins the merchant's next batch. **What to build** Create the transaction with the Sale type. There's no second call to make and no hold to manage. If the order is canceled before the batch closes, the undo is a cancel rather than a refund, so the money never moves. **Worth knowing** - Captured isn't settled. The payment sits in the open batch until settlement runs, so fulfillment logic that keys on capture is deciding on a hold, not on money. - Send an idempotency key with every create, so a retry after a timeout can't charge the customer twice. **Where to go next** - [Accept your first payment](https://devportal.qa.winkpg.io/docs/blueprints/accept-your-first-payment.md) - [Transaction lifecycle and settlement](https://devportal.qa.winkpg.io/docs/guides/transaction-lifecycle-and-settlement.md) - [Create a transaction](https://devportal.qa.winkpg.io/docs/api/transactionsCreate.md) ### Can the final amount change before you deliver? https://devportal.qa.winkpg.io/docs/decide/charge-now-or-authorize-first/can-the-final-amount-change.md A capture can go down from the amount you authorized, never up. Which way the total can move decides whether one authorization is enough. **Choose one** - It stays the same, or it can only go down. An item out of stock, or an order shipped in part. Leads to: Authorize now, capture what you deliver. - It can go up. An added item, a tip, or an extended stay. Leads to: Authorize, raise the hold if the order grows, then capture. #### Authorize now, capture what you deliver https://devportal.qa.winkpg.io/docs/decide/charge-now-or-authorize-first/authorize-then-capture-what-you-deliver.md Hold the funds when the customer orders, and take only what you actually shipped. **What to build** Create the transaction with the Authorization type when the customer orders. When you ship, send a Capture on the operations endpoint for the amount you delivered. A capture for less than the authorization releases the rest of the hold, so an out-of-stock line never reaches the customer's statement as a charge followed by a refund. **Worth knowing** - An authorization is captured once. Capturing less than you authorized releases the rest of the hold, and a second capture for the remainder is refused. - A hold expires on its own if nothing captures it. The card networks and the issuer set how long it lasts, and it's days rather than weeks, so capture as soon as you deliver. - To cancel an order you haven't shipped, cancel the authorization rather than capturing and refunding it. **Where to go next** - [Authorize now, capture later](https://devportal.qa.winkpg.io/docs/blueprints/authorize-now-capture-later.md) - [Transaction lifecycle and settlement](https://devportal.qa.winkpg.io/docs/guides/transaction-lifecycle-and-settlement.md) - [Run an operation on a transaction](https://devportal.qa.winkpg.io/docs/api/transactionOperationsExecuteOperation.md) #### Authorize, raise the hold if the order grows, then capture https://devportal.qa.winkpg.io/docs/decide/charge-now-or-authorize-first/authorize-and-raise-the-hold-if-it-grows.md Keep one authorization for the whole order and raise it, rather than adding a second payment beside the first. **What to build** Authorize the amount you know about when the customer orders. When the order grows, send an IncrementalAuthorization on the operations endpoint to raise the existing hold. Capture the final amount when you deliver. **Worth knowing** - An incremental authorization sends a new authorization message to the card network, so the issuer can refuse it. Decide in advance what you do with an order that grew past what the customer's bank would approve. - Not every processor supports incremental authorization. Check that the merchant's processor offers it before you design around it. - An authorization is captured once. Capturing less than you authorized releases the rest of the hold, and a second capture for the remainder is refused. **Where to go next** - [Authorize now, capture later](https://devportal.qa.winkpg.io/docs/blueprints/authorize-now-capture-later.md) - [Run an operation on a transaction](https://devportal.qa.winkpg.io/docs/api/transactionOperationsExecuteOperation.md) - [Transaction lifecycle and settlement](https://devportal.qa.winkpg.io/docs/guides/transaction-lifecycle-and-settlement.md) ### Store the payment method and charge it at delivery https://devportal.qa.winkpg.io/docs/decide/charge-now-or-authorize-first/store-the-payment-method-and-charge-at-delivery.md A hold won't last until you deliver, so keep the payment method instead and charge it when you're ready. **What to build** Store the customer's payment method when they order, along with their consent to a later charge. When you deliver, charge the stored payment method as a merchant-initiated transaction, because the customer isn't present at that moment. **Worth knowing** - A merchant-initiated charge needs a stored-credential consent that permits its reason, captured when the card is stored on a hosted payment page or in the Virtual Terminal. The direct API can't record that consent. - Optionally verify the card at order time, so a card that's going to fail is found while the customer can still give you another one. - The charge at delivery can be declined. Plan the message you send the customer when it is. **Where to go next** - [Reusing a stored payment method](https://devportal.qa.winkpg.io/docs/guides/reusing-saved-cards.md) - [Save a card and charge it later](https://devportal.qa.winkpg.io/docs/blueprints/save-a-card-and-charge-it-later.md) - [Understanding declines and rejections](https://devportal.qa.winkpg.io/docs/guides/understanding-declines-and-rejections.md) - [Decision guides](https://devportal.qa.winkpg.io/docs/decide.md): every decision guide this instance publishes. ## See also - [All documentation](https://devportal.qa.winkpg.io/llms.txt): the machine-readable index of every public page on this site.