Checkout Lifecycle

Provider-facing enrolment states only. This page does not describe payment collection.

Enrolment and mandate activation are two different lifecycles. Confirm uses setup complete. Authorised is mandate active only.

Enrolment

1Create checkoutYour server

2Direct debit setup requiredOpen setup URL

3Hosted BECS NZ setupPayer browser

4Setup completeGET until true

5Confirm checkoutYour server

6ConfirmedEnrolment complete

After confirmed, Salesforce creates the payment schedule and owns collection. Confirm does not collect money.

pending_submissionSetup can already be complete

submittedStill not Authorised

active / AuthorisedMandate active only

You may confirm during pending_submission or submitted. Do not treat those states as Authorised. Collection waits for Authorised.

After	Typical `checkout.status`	What you do
Successful create	`direct_debit_setup_required`	Open `direct_debit.setup_url` in the payer’s browser
Payer still in GoCardless	`direct_debit_setup_required`	Wait; GET checkout
Setup complete	still `direct_debit_setup_required` until confirm	Confirm when `direct_debit.setup_complete` is `true`
First confirm	`Confirmed` (`checkout.status: confirmed` on the response)	Enrolment is complete
Repeat confirm	same confirmed checkout	`already_confirmed: true`

Create — Your backend. Creates the checkout and a draft direct-debit authority. Returns setup URL and token. Does not collect money.

Hosted BECS NZ setup — Payer browser + GoCardless. Not an authenticated provider API call.

Setup complete — Billing Request fulfilled, mandate id present, mandate pending_submission, submitted, or active. See Direct Debit Setup.

Confirm — Your backend. Records declarations, stores the Payment Plan Agreement, marks the checkout confirmed. Does not collect money.

Confirmed — Enrolment is complete for this API.

GET /v1/provider-checkouts/{checkoutId}
Authorization: Bearer <YOUR_API_KEY>

Use GET to decide whether to open setup, wait, or confirm. Do not infer setup complete from the browser alone.