Put the customer on a billing contract

Describe the schedule once, and the platform charges the stored payment method on it, so your service never runs a billing timer.

Your answers so far

Is the customer there when each payment is taken?: No. We charge them without asking each time. Change
Is there a fixed amount on a fixed schedule?: Yes. The same amount, every period. Change

Choose one

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.

What this means for PCI

This is guidance rather than a compliance determination. Which questionnaire you are eligible for depends on your full environment, so confirm it with your QSA or your acquirer before you rely on it.

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

Start over