# Store the payment method and charge it at delivery

[Charge now or authorize first](https://devportal.qa.winkpg.io/docs/decide/charge-now-or-authorize-first.md): Whether to take the money in the same request as the approval, or hold the funds and capture them when you deliver.

A hold won't last until you deliver, so keep the payment method instead and charge it when you're ready.

**Your answers so far**

- When do you deliver what the customer paid for? Weeks later, or on a date nobody knows yet.

**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)

- [Start over](https://devportal.qa.winkpg.io/docs/decide/charge-now-or-authorize-first.md): go back to the first question.

## See also

- [All documentation](https://devportal.qa.winkpg.io/llms.txt): the machine-readable index of every public page on this site.