Disclosure Agreements

Overview

Widget ACH cashout requires the user to accept the latest Electronic Funds Transfer disclosure (type 6). ZBD tracks acceptance by disclosure type and version, so the user must accept a new type 6 version even if they accepted an older version before. Disclosure status does not block widget session creation. The disclosure APIs can also return types 1 through 5; those types do not block widget cashout and can be ignored for widget eligibility. Your contract or other ZBD services may impose separate legal requirements. Your application is responsible for presenting the Electronic Funds Transfer document and collecting the user’s acceptance. The widget does not render the document or record acceptance on the publisher’s behalf.

End-to-end Flow

Your server creates or resolves the widget user.
Your server reads `outstanding_disclosures` from the response or calls Get Disclosure Status.
If you offer ACH, your server checks whether disclosure type `6` is current.
If type `6` is outstanding, your application presents that document outside the widget.
Your server records type `6` acceptance with Submit Disclosure Acceptance.
Your server creates a widget session.
Your frontend opens the returned `widget_url`.
The user can continue to bank linking, identity verification, and cashout.

No disclosure type is checked when a widget session is created. Type 6 is checked only when an ACH cashout is submitted. Complete the publisher-side type 6 flow before opening the widget to avoid sending the user into a blocked ACH flow. Disclosure APIs require your server-side API key and must not be called from a browser, game client, or WebView.

Outstanding Disclosures on User Creation

You do not need a separate call to discover whether Electronic Funds Transfer type 6 is outstanding. The Create User response (POST /api/v1/widget/users) already includes an outstanding_disclosures array on that first user request. The array can contain types 1 through 5; ignore those entries for widget eligibility. For ACH, filter for type_id: 6. If no type 6 entry is present, the user is current for the widget ACH disclosure gate. outstanding_disclosures only lists what is still outstanding. When you need the complete picture — including which disclosures a user has already accepted and when — use the dedicated endpoints:

Get Disclosure Status — list every current disclosure type with the user’s acceptance state (tos_current, accepted_at); inspect type 6 for ACH.
Submit Disclosure Acceptance — record acceptance of the latest type 6 version from your server.

The same outstanding_disclosures shape also appears in the widget session status during a session (see Session Status). Create User is the initial snapshot at provisioning time; Get Disclosure Status is the source of truth for the full, up-to-date acceptance state.

Disclosure Types

The disclosure endpoints can report other types, but the widget has one required publisher-managed disclosure:

Disclosure type	Type ID	Used for
Electronic Funds Transfer	`6`	ACH bank payout authorization

ACH cashout submission requires the current Electronic Funds Transfer disclosure to be accepted. If the user has not accepted the latest type 6 version, the request is rejected before payout processing. Type 6 is not required for SCT cashout. Types 1 through 5 do not block widget cashout, and no disclosure type blocks widget session creation.

Session Status

During a widget session, ZBD can return all outstanding disclosure information as a read-only status. The field is named outstanding_disclosures. This does not cause the widget to display documents or collect acceptance. Only an outstanding type 6 entry affects widget ACH eligibility. Types 1 through 5 can remain outstanding without blocking the session or cashout. Example session status shape:

{
  "success": true,
  "data": {
    "id": "4ac4fd8a-cc2c-4d03-af09-a76f4e89d652",
    "email": "player@example.com",
    "is_id_verified": true,
    "kyc_tier": 2,
    "kyc_status": "approved",
    "capabilities": [],
    "outstanding_disclosures": [
      {
        "id": 12,
        "type_id": 6,
        "name": "Electronic Funds Transfer",
        "description": "Electronic Funds Transfer Agreement.",
        "version": "1.0.0",
        "content_uri": "https://...",
        "created_at": "2026-06-24T20:11:45Z",
        "due_date": "2025-08-11T00:00:00"
      }
    ]
  },
  "message": "Session account status retrieved successfully.",
  "error": null
}

If outstanding_disclosures contains type 6, return the user to the publisher-side EFT acceptance flow before ACH cashout. Do not block widget access because the array contains only types 1 through 5. Use the widget disclosure APIs from your server to check and record type 6 acceptance before ACH cashout. The API key determines the project context, so these endpoints only require the widget user ID in the path.

Disclosure endpoints require your server-side API key. Do not call these endpoints directly from a browser, mobile client, game client, or WebView.

Use Get Disclosure Status to check type 6 and Submit Disclosure Acceptance to record acceptance of its latest version.

Existing Users

Disclosure acceptance is versioned. If an existing user needs to accept the current Electronic Funds Transfer disclosure, submit type 6 with the endpoint above. Do not rely on an idempotent user-create call to update disclosure acceptance for an existing user. User creation can return an existing user without recording new disclosure acceptance.

Sandbox

Sandbox uses the same type 6 status and acceptance model as production. When testing disclosure handling, use your sandbox API key and sandbox API base URL:

https://sandbox-api.zbdpay.com

Some sandbox bypass settings can skip cashout checks for faster testing. If you specifically need to verify that ACH is blocked by missing type 6 acceptance, make sure your sandbox setup is not bypassing the disclosure gate.

Overview

Events

API Reference

Testing

Overview

End-to-end Flow

Outstanding Disclosures on User Creation

Disclosure Types

Session Status

Recording acceptance before the widget

Existing Users

Sandbox

​Overview

​End-to-end Flow

​Outstanding Disclosures on User Creation

​Disclosure Types

​Session Status

​Recording acceptance before the widget

​Existing Users

​Sandbox

Overview

End-to-end Flow

Outstanding Disclosures on User Creation

Disclosure Types

Session Status

Recording acceptance before the widget

Existing Users

Sandbox