Enable BNPL for a partner

Purpose

FPH administrators control which partners may configure buy-now-pay-later payment plans. This permission belongs to the selected partner. Event organizers still choose event-specific terms and eligible resources after platform permission is granted.

Change the partner permission

1. Open Admin Partners.
2. Find the intended partner and choose BNPL settings.
3. Check the partner name, saved permission, revision and activation readiness.
4. Change Allow BNPL for this partner and enter a reason of 10–500 characters.
5. Save, review the confirmation and complete the fresh MFA check when requested.
6. Wait for the confirmed saved permission and revision before leaving the page.

New partners default to off. A saved permission does not create an agreement, change attendee consent or enable every event. Checkout also requires the released service capabilities, required notification transport and a valid event policy. The editor reports saved permission and readiness separately.

Turn BNPL off

Disable the same partner permission to stop new financed agreements. Existing agreements retain their payment, refund, cancellation and history workflows. Disabling does not erase amounts already owed, accepted terms or operational records.

The API and database enforce the permission at agreement creation. A stale browser cannot authorize a new agreement after the administrative change has taken effect.

Recover a failed save

If another administrator changed the revision, reload and review the current saved permission before preparing a new change. If the response is uncertain, retain the original request and use the editor’s retry/reload flow. A repeated original request must not apply the change twice.

Changing partner or account clears the previous editor context. An unavailable policy is displayed as unavailable and cannot be treated as confirmed enabled. Checkout readiness becoming unavailable does not prevent disabling a saved permission.

Access and evidence

Only FPH administrators may use this control. Writes require fresh MFA and record a reason, request identity and versioned administration audit. Partner event settings cannot grant platform permission.

Local checks cover administrator/MFA boundaries, partner isolation, stale revisions, idempotent retries, agreement-creation fencing and desktop/mobile interactions with intercepted writes. These fixtures do not prove live provider delivery or a signed-in production enablement. Production partners remain off until an administrator explicitly enables them.

Feature availability

The published registration, dealer and shop checkout implementations still require partner permission, eligible event terms and service readiness. The attendee amendment editor remains held off in Rego. Email servicing repair and reply-by-email website reports also require their separate transport configuration and acceptance checks. Publishing their source does not remove those gates or prove recipient delivery.