Skip to content

Certification programme

From application to certified integration

An application moves through vetting, a sandbox phase and a certification review. The stages and checks below are served by the portal API, so they always match what officers apply.

Apply for sandbox access

Stages

  1. 01Draft

    The application is being prepared and can still be edited.

  2. 02Submitted

    The application is waiting for the certification team.

  3. 03In vetting

    The certification team is working through the vetting checks.

  4. 04Approved for sandbox

    Sandbox access is approved for the listed services. Issue credentials from the portal.

  5. 05Sandbox active

    Sandbox credentials are issued. Build against staging with mock data and record certification evidence.

  6. 06Certification review

    Evidence is submitted and under review.

  7. 07Certified

    The integration passed certification.

Rejected
The application was not approved.
Suspended
Access is paused and sandbox credentials are revoked.
Revoked
Access is withdrawn and sandbox credentials are revoked.

Production access is not a portal stage.

Vetting checks

  • Organisation identity confirmedAll services

    The applying organisation is a registered legal entity and the applicant is authorised to act for it.

  • Named technical contactAll services

    A named individual with their own identity account owns the integration. No shared sign-ins.

  • Use case matches the requested servicesAll services

    The stated use case needs every service requested and nothing broader.

  • Data protection postureAll services

    The organisation states its lawful basis for any personal data it will process and where that data is held.

  • Sandbox terms acknowledgedAll services

    The organisation acknowledges sandbox credentials reach staging with mock data only and are never used with real customer data.

  • Security contactAll services

    A security contact is named for incident and credential-compromise notices.

Certification checks

  • Credentials held server-sideAll services

    The sandbox key lives only in server-side secret storage, never in a browser, a mobile bundle, a log or a source repository.

  • Credential rotation exercisedAll services

    The key was rotated through the portal at least once and the integration kept working on the new key.

  • 401 and 429 handlingAll services

    A 401 is treated as a configuration fault (no retry loop); a 429 backs off and honours Retry-After.

  • Event ids and dedupe keys carry no personal data (tokenise at source)Customer 360

    No event id, dedupe key or other identifier field embeds a phone number, email address, national id, name or account number. Where a stable per-person key is needed it is tokenised at source before it is sent.

  • Idempotent ingestCustomer 360

    Every event carries a stable event id so a retried or replayed send is recognised as the same event, not a duplicate.

  • Reads confined to the partner's own sourceCustomer 360

    Feed and count reads are made with the read:own scope and handle the 403 returned for any other source.

  • Brand bindingNotification Hub

    Every send names the sandbox brand the key is bound to; the integration never assumes it may send under another brand.

  • 403 and 429 handlingNotification Hub

    A 403 (brand or scope not allowed) is surfaced as a configuration fault without retries; a 429 backs off and honours Retry-After.

  • Sandbox status handlingNotification Hub

    A message recorded with the sandboxed status is treated as a completed sandbox send and never as delivered or as a failure to retry.

  • Example recipients onlyNotification Hub

    Sandbox sends use reserved example recipients only (for example addresses at example.com), never a real person.

  • Webhook signature verificationBanking Partner API

    Every webhook is verified by recomputing the X-ZB-Signature HMAC-SHA256 over the raw request body with a constant-time comparison, and rejected when it does not match.

  • Idempotent intent creationBanking Partner API

    Payment intents are created with an Idempotency-Key so a retried request cannot create a second intent.

  • Intent expiry handlingBanking Partner API

    An intent that expires before the customer authorises it is handled as a final state (order released, customer told) and a fresh intent is created if the customer returns.

  • Webhook deduplicationBanking Partner API

    Webhook retries are deduplicated on X-ZB-Event-Id so one event is processed once.