Automatic collection
Charge a customer's saved card automatically when a subscription invoice is finalized.
When a subscription invoice is finalized, yRecurring can charge the customer's saved card on its own, without anyone pressing a button. This is automatic collection. It runs off-session, just after the invoice is finalized, and it is how most recurring revenue is collected.
If a charge fails, dunning takes over and retries on a schedule. Automatic collection is the first charge; dunning is the recovery.
The two switches
Whether an invoice is auto-charged depends on two settings, and both have to say yes.
- The organization master switch. Your whole organization has one automatic-collection switch, on by default. Turn it off and no invoice is auto-charged anywhere; every invoice waits for a manual or customer-made payment instead. You change it under Settings, on the billing behavior preferences (open settings if you are signed in).
- The customer setting. Each customer has an automatic-collection setting, on by default. Turn it off for a customer and their invoices are sent for them to pay rather than charged. This is how you run invoice-pay customers (net terms, pay by bank transfer) alongside auto-charged ones. A single subscription can override its customer's setting.
What it needs to charge
Even with both switches on, a charge needs two things in place:
- A connected payment gateway for your active mode, so there is somewhere to send the charge.
- A saved card on file for the customer, in the invoice's billing entity.
If either is missing, nothing is charged and the invoice is left for manual payment. The reason is recorded on the invoice so you can see and fix it.
What can happen
A single auto-collection attempt ends in one of these outcomes:
| Outcome | What it means |
|---|---|
| Charged | The saved card was charged and the invoice settled, in full or in part. |
| Pending | The charge is on a slow rail (ACH or SEPA) and is still clearing. A settlement message resolves it later. |
| Needs authentication | The card is alive but the bank wants the customer to confirm the payment (3DS / SCA). yRecurring does not blind-retry these. The customer gets an email with a link to confirm the payment. |
| Failed | The gateway declined, or something went wrong. Dunning picks it up and retries. |
| Skipped | No charge was attempted. See the reasons below. |
Important
A "needs authentication" charge is not a failure and is not retried on its own. The customer has to confirm it from the link in their email. Until they do, the invoice stays unpaid.
Why an invoice was skipped
When no charge is attempted, the reason is one of these. The first two are normal setup choices and stay quiet. The last three point to something you can fix, so they are recorded on the invoice.
| Reason | Meaning |
|---|---|
| Auto-collection is off for the organization | The master switch is off. |
| The customer is set to manual collection | The customer, or its subscription, is set to be invoiced rather than charged. |
| No gateway is configured | There is no payment gateway to charge against. Connect one. |
| No saved card | The customer has no active card on file. They need to add one. |
| Nothing to collect | The invoice is already paid or has nothing left owing, for example when account credit covered it. |
Turning it off
If you turn off automatic collection, for the organization or for one customer, invoices are still finalized and sent. The customer can pay from the hosted invoice page, or you record the payment when it arrives another way.
Edge cases
- Both switches must be on. The organization switch and the customer switch each have to allow it. Either one off means no auto-charge.
- A subscription can override its customer. Set a subscription to manual and it is invoiced even if the customer is on auto-charge.
- A fixable gap is never silent. A missing gateway or a missing card is written on the invoice so you can act on it.
- A failed charge starts dunning; a "needs authentication" one does not retry. One goes to the retry schedule, the other waits for the customer to confirm.
The backup payment method
A customer can have one backup card alongside their default. When an automatic charge on the default card declines, the backup is tried right away, in the same collection pass. Only if both fail does dunning begin, and the recovery emails talk about the default card, since that is the customer's main instrument.
Set or clear the backup from the customer page, in the payment methods section. A card that is removed stops being the backup automatically. The backup is only used when the default actually declines: a charge waiting on bank confirmation or on the customer's authentication never falls through to it, and neither does a charge whose outcome we could not read.
Worth knowing before you set one: the backup is tried on every collection attempt, not just the first. So a customer with a backup makes two charge attempts per dunning retry instead of one. That is the point of a backup, but it also means two sets of decline fees from your gateway if both cards keep failing, and some banks count repeated attempts against a card. If your gateway charges per declined attempt, set backups where they will actually help rather than on every customer.