Do I have to build a billing engine?

No. The schedule, the retries, and the token management are part of the method. Your side is the first payment and a decision about amount and interval.

What happens when a customer's card expires?

The stored card is a network token, which follows the cardholder through reissues and expiries — so the subscription that would previously have broken keeps charging.

Can a customer pay for a subscription with a wallet?

Yes. The card behind Apple Pay or Google Pay can be tokenized for recurring charges, so a subscription started with one tap continues without them returning to the checkout.

How do I refund one month rather than everything?

Each cycle is its own order, so you refund that order — full or partial — without affecting any other cycle or cancelling the subscription itself.

/// Method · Recurring

Subscriptions that don't quietly break.

Recurring revenue fails in two boring ways: a card is reissued and the charge stops working, or a renewal soft-declines and nobody notices until the customer is gone. Network tokens fix the first, scheduled retries fix the second, and both happen without your team building a billing engine.

See Protocore Gateway All payment methods

Yours

Schedule and amount

Auto

Retried on soft decline

Token

Survives card reissues

Order per cycle

/// How it runs

[ 01 ]
AUTHORIZE
The customer pays once on the checkout; the card is vaulted as a network token.
[ 02 ]
SCHEDULE
You define the amount, interval, start, and end — or leave it open.
[ 03 ]
CHARGE
Each cycle produces its own order, its own receipt, and its own webhook.
[ 04 ]
RECOVER
A soft decline is retried on a schedule rather than written off as churn.

/// 01

Every cycle is a real order

A subscription isn't a special object with its own reporting — each charge produces an order, a receipt, and a webhook exactly like a one-off payment. That means a subscription reconciles line by line, a single month can be refunded without unwinding the whole relationship, and your finance team doesn't need a second mental model for recurring revenue.

[ 01 ]One order, one receipt, and one webhook per cycle
[ 02 ]Refund a single cycle without touching the others
[ 03 ]Reconciles in the same list as one-off payments

/// 02

The two failures that actually cost money

Involuntary churn is mostly two things: expired or reissued cards, and soft declines that nobody retried. Network tokens follow the cardholder through a reissue, so the charge keeps working when a new card arrives. Scheduled retries take another run at a temporary decline, at times chosen to have a better chance than the first attempt.

[ 01 ]Network tokens survive reissues and expiries
[ 02 ]Soft declines retried on a schedule, not abandoned
[ 03 ]The customer is only told when it actually matters

/// 03

What it takes to switch on

One flag on the first payment to vault the card, and a schedule. There's no separate billing product to integrate, and the subscription's charges land in the same back office and the same payout as everything else you take.

/// FAQ

Recurring payments — questions merchants ask.

No. The schedule, the retries, and the token management are part of the method. Your side is the first payment and a decision about amount and interval.
The stored card is a network token, which follows the cardholder through reissues and expiries — so the subscription that would previously have broken keeps charging.
Yes. The card behind Apple Pay or Google Pay can be tokenized for recurring charges, so a subscription started with one tap continues without them returning to the checkout.
Each cycle is its own order, so you refund that order — full or partial — without affecting any other cycle or cancelling the subscription itself.