# Charge a customer again Whether repeat payments run on a contract the platform bills, on a schedule of your own, on an invoice, or at your checkout, and what the card networks need from each. 3 questions, 4 outcomes ## Is the customer there when each payment is taken? https://devportal.qa.winkpg.io/docs/decide/charge-a-customer-again/is-the-customer-there-for-each-charge.md The card networks classify every charge on a stored payment method by this, and the platform reports it to the processor for you. **Choose one** - No. We charge them without asking each time. A subscription, an installment plan, or a charge after the order. Leads to: Is there a fixed amount on a fixed schedule?. - Yes. They agree to each payment as it happens. They come back to buy again, or they pay a bill you send them. Leads to: How does the customer pay each time?. ### Is there a fixed amount on a fixed schedule? https://devportal.qa.winkpg.io/docs/decide/charge-a-customer-again/is-there-a-fixed-amount-and-schedule.md A schedule someone could write down in advance is a contract the platform can run. Anything else has to be triggered by your own system. **Choose one** - Yes. The same amount, every period. A monthly membership, or a known total split into equal payments. Leads to: Put the customer on a billing contract. - No. The amount or the timing depends on what happens. Usage billed in arrears, a no-show fee, or a balance settled on delivery. Leads to: Charge the stored payment method when you need to. #### Put the customer on a billing contract https://devportal.qa.winkpg.io/docs/decide/charge-a-customer-again/put-the-customer-on-a-billing-contract.md Describe the schedule once, and the platform charges the stored payment method on it, so your service never runs a billing timer. **What to build** Create the customer, store their payment method, and create a contract that names it with the amount and the schedule. The platform's daily billing run charges each contract that's due, reports each charge as merchant-initiated, and applies the contract's own limits: a maximum number of payments, a maximum failure count, and the backoff after a failure. Don't build a nightly job that walks your own subscriber table and posts sales; that job would re-implement all of this. **Worth knowing** - A charge the customer isn't present for needs a stored-credential consent that permits it, captured when the card is stored on a hosted payment page or in the Virtual Terminal. The direct API can't record consent, and a later charge can't add a usage the customer didn't agree to, so ask for every usage you expect to need when the card is stored. - On a sandbox merchant, a test key can ask for a billing run straight away rather than waiting for the daily one, so you can watch a renewal happen. - Subscribe to the recurring-billing webhook events for charge succeeded, charge failed, and contract ended, rather than polling contracts for changes. **Where to go next** - [Bill a customer on a schedule](https://devportal.qa.winkpg.io/docs/blueprints/bill-a-customer-on-a-schedule.md) - [Create a contract](https://devportal.qa.winkpg.io/docs/api/contractsCreate.md) - [Run billing now on a sandbox merchant](https://devportal.qa.winkpg.io/docs/api/sandboxRecurringBillingRunNow.md) - [Reusing a stored payment method](https://devportal.qa.winkpg.io/docs/guides/reusing-saved-cards.md) #### Charge the stored payment method when you need to https://devportal.qa.winkpg.io/docs/decide/charge-a-customer-again/charge-the-stored-payment-method-when-you-need-to.md Your system decides when and how much, and charges the stored payment method as a merchant-initiated transaction. **What to build** Create the transaction with the stored payment method's token, initiationType set to MerchantInitiated, a mitReason, and the owning customer's id. The platform finds the customer's active consent for that reason itself, so don't look up or send a consent id. Use UnscheduledCOF for a charge with no fixed schedule. **Worth knowing** - A charge the customer isn't present for needs a stored-credential consent that permits it, captured when the card is stored on a hosted payment page or in the Virtual Terminal. The direct API can't record consent, and a later charge can't add a usage the customer didn't agree to, so ask for every usage you expect to need when the card is stored. - A merchant-initiated charge without the customer's id is refused before any consent is checked, and one with no matching consent is declined with stored_credential_consent_required. - Your system owns the retry policy here. Follow the platform's decline classification: retry only funding and availability declines, spaced by days, and stop on anything else. **Where to go next** - [Reusing a stored payment method](https://devportal.qa.winkpg.io/docs/guides/reusing-saved-cards.md) - [Create a transaction](https://devportal.qa.winkpg.io/docs/api/transactionsCreate.md) - [Understanding declines and rejections](https://devportal.qa.winkpg.io/docs/guides/understanding-declines-and-rejections.md) - [Retry a payment without a double charge](https://devportal.qa.winkpg.io/docs/blueprints/retry-a-payment-safely.md) ### How does the customer pay each time? https://devportal.qa.winkpg.io/docs/decide/charge-a-customer-again/how-the-customer-pays-each-time.md A bill they pay from a link and a checkout they return to are different integrations, even when the card behind them is the same. **Choose one** - From a bill we send them. Line items, a due date, and a record of what they owe. Leads to: Send an invoice. - At our checkout, where they pick a card they stored before. A returning customer placing another order. Leads to: Offer the stored payment method at checkout. #### Send an invoice https://devportal.qa.winkpg.io/docs/decide/charge-a-customer-again/send-an-invoice.md The customer gets a numbered bill with a link to pay it, and you get a record that moves from issued to paid. **What to build** Create the customer, write the invoice as a draft, and send it. Sending issues the draft, assigns its number, mints a payment link, and notifies the customer. When they pay by another route, such as a check or a bank transfer, record the payment against the invoice so it reads as paid. **Worth knowing** - Issuing locks an invoice. Get the line items right while it's a draft. - Sending needs a delivery destination the merchant has configured. Check that before you rely on the platform to notify the customer. **Where to go next** - [Invoice a customer and get paid](https://devportal.qa.winkpg.io/docs/blueprints/invoice-a-customer-and-get-paid.md) - [Send an invoice](https://devportal.qa.winkpg.io/docs/api/invoiceLifecycleSend.md) #### Offer the stored payment method at checkout https://devportal.qa.winkpg.io/docs/decide/charge-a-customer-again/offer-the-stored-payment-method-at-checkout.md The customer picks the card they stored last time, and the charge is cardholder-initiated because they're there to agree to it. **What to build** Charge the stored payment method's token with initiationType set to CardholderInitiated, or leave the field out: an omitted value is treated as cardholder-initiated. Send the customer's id too, so the token resolves for the customer who owns it. No consent is consulted, so this works for any active stored payment method. **Worth knowing** - Don't report a charge the customer is agreeing to as merchant-initiated. It isn't refused, but it misreports the charge to the card networks, which price and dispute the two kinds differently. - Treat the token as a credential. Store only the opaque public reference the platform hands you, and retire it when the customer removes the card. **Where to go next** - [Save a card and charge it later](https://devportal.qa.winkpg.io/docs/blueprints/save-a-card-and-charge-it-later.md) - [Reusing a stored payment method](https://devportal.qa.winkpg.io/docs/guides/reusing-saved-cards.md) - [Create a transaction](https://devportal.qa.winkpg.io/docs/api/transactionsCreate.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.