For the complete documentation index, see llms.txt. This page is also available as Markdown.

Sample Payload

These examples show current request shapes for onboarding application submission.

Use this page when you need a working reference for:

  • creating a short onboarding application

  • creating a full onboarding application

  • configuring fees

  • sending an application directly to the signer

  • creating a Draft application when attachments are required

For most Sandbox testing, use submitImmediately: true. This creates the application and immediately sends it to the signer.

If you need to upload attachments before the signer receives the application, use submitImmediately: false, upload attachments while the application is in Draft status, then submit the Draft application for signature.

Short application sample

The short application endpoint is:

POST /merchant-onboarding/applications-short

Use this request when you want to start onboarding with basic merchant, signer, fee, and crypto environment details. The hosted onboarding flow collects the remaining merchant information from the signer.

Full application sample

The full application endpoint is:

Use this request when you already have the merchant’s business, stakeholder, banking, and fee details and want to prefill the onboarding application.

In the full application flow, merchant details are sent inside merchantData. The application signer is identified inside merchantData.stakeholders by setting isApplicationSigner to true.

Draft application sample

Use submitImmediately: false only when the application must remain in Draft status before it is sent to the signer.

This is required when you need to upload attachments before the signer receives the application.

After the Draft application is created, upload attachments while the application is still in Draft status.

Then submit the Draft application for signature.

Fee information reference

The feeInformation object defines the pricing values displayed to the signer during onboarding.

Fee values should be provided when creating applications that are sent directly to the signer. These values are rendered in the signing experience and should be reviewed before the application is submitted.

Each fee object includes:

Field
Description

sellRate

The rate or fixed amount charged for the fee.

isBilledByPartner

Indicates whether the fee is billed by the partner instead of Bead.

Settlement fees

Some partner configurations may also include additional settlement-related fees, such as wire settlement pricing, when applicable to the agreement and supported by the onboarding configuration.

Crypto fees

Use bitcoinFee for Bitcoin pricing and stablecoinFee for stablecoin pricing.

Digital wallet fees

Use digitalWalletsFees for wallet and BNPL pricing.

Each digital wallet fee entry identifies:

Field
Description

tenderType

The wallet or BNPL tender being priced.

paymentLocationType

Whether the pricing row applies to inStore or online.

transactionRate

Percentage-style transaction rate.

perItemFee

Fixed per-item fee.

refundFee

Fixed refund fee.

chargebackFee

Fixed chargeback fee.

For each wallet tender being priced, send both inStore and online rows. Bead may treat these values the same today for some tenders, but both values are accepted and reserved for future pricing separation. If your commercial terms do not distinguish online and in-store pricing, send the same values for both.

Example response

A successful application create response includes identifiers you should store for status tracking, troubleshooting, and follow-up commands.

If the application was created with submitImmediately: false, the initial status may be draft.

Best practices

  • Use the short application sample for fast Sandbox testing.

  • Use the full application sample when your system already has most merchant details.

  • Use submitImmediately: true for the simplest signer flow.

  • Use submitImmediately: false only when attachments need to be uploaded before the signer receives the application.

  • Store applicationId and envelopeId immediately after creation.

  • Include isBilledByPartner on all fee objects.

  • Use bitcoinFee and stablecoinFee for crypto fee configuration.

  • Send both inStore and online rows for each digital wallet tender you are pricing.

  • Confirm all fee values before sending the application to the signer.

Last updated