Hosted Enrolment Checkout
Hosted Enrolment Checkout is the NZ product where StudentPay owns the enrolment UX. Use it when the education provider does not want to build create / status / confirm screens.
This is not Enrolment Integration. Embedding or copying the hosted app is not a substitute for the Integration API.
Do not treat /enrol/bela-beauty/ or /api/demos/bela-beauty/* as this
product. Those are a StudentPay sandbox demonstration UI, not the reusable
hosted engine and not the Integration contract.
Architecture
Student
↓
StudentPay hosted enrolment (provider-branded)
↓
StudentPay backend (API key stays server-side)
↓
POST/GET/confirm /v1/provider-checkouts
↓
GoCardless hosted BECS NZ setup
↓
StudentPay confirm → Payment Plan Agreement + charge schedule
The financial state machine is the same /v1 machine documented for
Enrolment Integration:
- Bearer authentication against a provider-specific key
- PIC must be Active, API-enabled, and environment-matched
- Hosted BECS NZ mandate via
setup_url - Confirm gated on
setup_complete - Payment Plan Agreement PDF stored on first confirm
- Residual final instalment conserved in the schedule
Who owns what
| StudentPay owns | Provider owns |
|---|---|
| Hosted enrolment screens | The public course catalogue on the provider website (typically deep-linked into hosted checkout) |
| Course/commercial values used at checkout | Marketing copy on the provider site |
| Server-side API key | Deciding that Hosted Checkout is the enrolment channel |
| GoCardless setup, confirm, PPA, schedules | Student support after enrolment, in the usual StudentPay operations tools |
For Hosted Checkout, the browser does not supply the authoritative course price. Course data is resolved from StudentPay-controlled server configuration.
Catalogue-authoritative Enrolment Integration (OLI_NZ, BELA_NZ) uses the
same commercial terms: the provider sends course.course_code and StudentPay
resolves price and plan maths. See Current contract.
Typical student journey
- The student opens a hosted enrolment URL for the provider (often a course-specific deep link).
- The student reviews the course and plan, enters details, and accepts declarations.
- The student is sent to GoCardless to complete BECS NZ bank setup.
- StudentPay reads
setup_completeand confirms the enrolment. - The Payment Plan Agreement is generated and stored. Salesforce originates the charge schedule. If the course has an initial payment, that amount is a Charge_Schedule due on confirmation and is collected by Direct Debit after enrolment. Hosted copy should describe it as an initial payment, not an account-validation fee, and must not promise settlement within 24 hours.
The typical student entry is a provider-branded hosted URL. The production
hosted origin is https://enrol.studentpay.co.nz (course-specific deep links
under /enrol/{provider}). StudentPay issues the exact tenant URL.
Providers do not call /v1 from browser JavaScript on this path.
Production status
NZ Hosted Enrolment Checkout has completed production certification against a live provider configuration.
StudentPay coordinates Production enablement for additional hosted tenants. Do not create an unsolicited Production enrolment to “test” hosted checkout.
Sandbox remains the place to rehearse the GoCardless BECS NZ journey.
If you need to own the UX instead
If your SIS, CRM, or website must own the enrolment screens, use Enrolment Integration from your backend. Do not scrape, fork, or white-label Hosted Checkout as that product.