How access follows your billing provider

Checkout writes a grant once, at the purchase. After that, your billing provider decides what happens to it. Each grant from checkout records the billing provider’s id for the user subscription it paid for. Whenever EdgeKit syncs that record, or an invoice or a transaction for it, it works out what the grant should be and moves it there.

EdgeKit reads its synced copy of the billing provider’s record each time. It never trusts the contents of a notification, so notifications that arrive out of order or twice change nothing extra.

Which grants follow the billing provider

Only grants written by checkout. A user subscription in your billing provider that never went through EdgeKit checkout has no grant, and EdgeKit does not create one from it. Users who bought before your organization used EdgeKit get no access from their existing record in your billing provider.

What each change does

In your billing provider	What happens to the grant
A renewal: the current period now ends later	Its expiry moves to the new period end.
A payment fails and the account goes past due	Depends on Access during dunning, below. While the user subscription’s status is past due, the expiry does not move.
The payment is collected	A grant suspended for dunning becomes active again.
The user subscription is paused	Depends on Access during pause, below.
A paused user subscription becomes live again	A grant suspended for the pause becomes active again.
It is cancelled: it will not renew	Nothing is written. The grant runs to its expiry and then stops giving access.
It ends at or after the grant’s expiry	Nothing is written. The grant has already expired.
It ends before the grant’s expiry	The grant is revoked, with a reason.
It ends while the grant is suspended	The grant is revoked, with a reason.
It has a future start	Nothing yet.

A refund or a chargeback on its own does not withdraw access. It sets the reason when the user subscription ends early.

Status reasons

A grant that is not active carries one reason:

• dunning: suspended for an unpaid invoice, or revoked because the user subscription ended for non-payment.
• paused: suspended for a pause.
• refund or chargeback: revoked, and the current period had a refund, or the user subscription had a chargeback in any period. A chargeback wins over a refund.
• billing_provider_terminated: revoked because the billing provider ended the user subscription for any other reason.

A revoked grant never becomes active again. If a refund or chargeback arrives after the grant was revoked as billing_provider_terminated, the reason is corrected and the status stays revoked.

The grants list in Identity › Audience › Grants shows each grant’s status and reason. Each grant’s screen shows its history: every transition, when it happened, who made it (the billing provider, for these) and the billing provider’s reference.

Your access policy

Two settings decide what a failed payment and a pause do. Both apply to your whole organization, and the console shows them read-only, as Access during dunning and Access during pause under Configuration on each site’s screen in Delivery › Delivery › Sites. EdgeKit sets them for your organization.

Access during dunning:

• grant, the default: access continues while your billing provider retries the payment. If your billing provider gives up and ends the user subscription before the grant’s expiry, the grant is revoked with dunning.
• suspend: an unpaid invoice suspends the grant with dunning until it is paid.

Access during pause:

• suspend, the default: a pause suspends the grant with paused. No access now, and the expiry does not change.
• grant: access runs to the end of the paid period and the grant then expires. The pause takes effect at that end.

The policy rides your deployment, so a new value applies from the next deploy.

How fast a change reaches the user

The grant moves when EdgeKit syncs the billing provider’s record, which follows the notification your billing provider sends.

In the browser, decisions read a signed copy of the user’s grants. It is made when the user’s EdgeKit session is read, lasts 15 minutes, is extended while the user keeps reading, and is never used more than one hour after it was made. So a grant change can take up to an hour to reach a user who keeps reading. A server’s decide request for a user reads their grants directly.

What EdgeKit never does

• It never writes to your billing provider from a grant change, and never cancels, refunds or pauses anything there. Do those in your billing provider.
• It never puts a price or a currency on a grant. Money lives in your billing provider’s records, which the Billing provider screens show. See Read your billing provider’s records.