Onboarding via link [US only]

This guide applies only to US-based entities who want to use ACH payments. Entities from other countries should use API-only onboarding.

Overview

In order to allow a US-based entity to use Monite’s payments rails, you have to onboard this entity for payment acceptance.

If the partner does not store in the Monite system the entity onboarding requirements, i.e. the information necessary for using the Monite payment rails, the entity itself will have to provide the necessary information about its business by following a link that will take them to a branded onboarding page.

The steps below describe the full payments acceptance onboarding flow via link:

  1. Create an entity.
  2. Assign payment methods.
  3. Get the payments onboarding link.
  4. The entity fills the payments onboarding form.
  5. Track the payments onboarding status changes.

Roles and permissions

Most endpoints mentioned in this guide require a partner-level access token.

The GET /onboarding_requirements can also be called with an entity user access token if this user has a role with the read permission for onboarding.

1. Create an entity

An entity is a party (person or business) that makes or receives payments. To learn how to create and manage entities that represent your customers, see Entities.

2. Subscribe to webhooks

To get notified about the onboarding progress of your entities, subscribe to the entity.onboarding_requirements.status_updated webhook. To do this, call POST /webhook_subscriptions with the following request body, replacing the url with the URL of your webhook listener endpoint:

1curl -X POST 'https://api.sandbox.monite.com/v1/webhook_subscriptions' \
2 -H 'X-Monite-Version: 2024-01-31' \
3 -H 'Authorization: Bearer YOUR_PARTNER_TOKEN' \
4 -H 'Content-Type: application/json' \
5 -d '{
6 "object_type": "entity",
7 "event_types": [
8 "onboarding_requirements.status_updated"
9 ],
10 "url": "https://example.com/your-webhook-listener"
11 }'

3. Assign payment methods

To specify the payment methods that an entity expects to be using, call PUT /entities/{entity_id}/payment_methods. In the request body, the payment_methods_receive list specifies the methods by which the entity can receive payments from its counterparts, and the payment_methods_send list specifies the methods that the entity can use to make payments to others.

The following example enables the ACH payment method for an entity:

1curl -X PUT 'https://api.sandbox.monite.com/v1/entities/3fa85...fa6/payment_methods' \
2 -H 'X-Monite-Version: 2024-01-31' \
3 -H 'Authorization: Bearer YOUR_PARTNER_TOKEN' \
4 -H 'Content-Type: application/json' \
5 -d '{
6 "payment_methods_send": [
7 "us_ach"
8 ]
9 }'
  • Some payment methods can be used both to send and receive payments, while others can be used only to send or only to receive payments.
  • Currently, us_ach can only be used in payment_methods_receive and cannot be used in payment_methods_send.

The steps below are optional if the chosen payment methods do not require onboarding for payments.

The entity must access a specific link to initialize its onboarding for payments acceptance. To get this link, call POST /onboarding_links with the entity ID in the X-Monite-Entity-Id field and with the request body containing the following fields:

  • refresh_url - the URL on your platform to which the entity user should be redirected if the original onboarding link has expired or was already visited;
  • return_url - the URL on your platform to which the entity will be redirected after the onboarding process.
  • expires_at - the date and time when this link will expire (in the ISO 8601 format).
1curl -X POST 'https://api.sandbox.monite.com/v1/onboarding_links' \
2 -H 'X-Monite-Version: 2024-01-31' \
3 -H 'X-Monite-Entity-Id: ENTITY_ID' \
4 -H 'Authorization: Bearer YOUR_PARTNER_TOKEN' \
5 -H 'Content-Type: application/json' \
6 -d '{
7 "refresh_url": "https://example.com/expired-link",
8 "return_url": "https://example.com/onboarding-complete",
9 "expires_at": "2024-04-01T00:00:00Z"
10 }'

The response contains the url of Monite-hosted onboarding page that the entity can use to proceed with its onboarding.

1{
2 "refresh_url": "https://example.com/expired-link",
3 "return_url": "https://example.com/onboarding-complete",
4 "expires_at": "2024-04-01T00:00:00Z",
5 "id": "76047531-2737-4075-b3f6-7f1f42eb78c1",
6 "entity_id": "37156af0-fbf7-44f7-b375-42e4d98733e2",
7 "url": "https://example.com/onboarding-link-for-this-entity"
8}

5. The entity fills the payments onboarding form

Next, redirect the user to onboarding url you obtained on the previous step. This onboarding page will prompt the user to fill in information about their entity.

After the user completes filling the form, Monite will redirect the user to the return_url you provided earlier.

6. Track the payments onboarding status

6.1. Webhooks

Assuming you have subscribed to the payment webhooks, you will receive the entity.onboarding_requirements.status_updated webhook event whenever an entity’s onboarding status is changed. The event payload contains entity_id that can be used to identify the affected entity:

1{
2 "id": "8cac4aa7-09c0-40e7-94a3-54adb9cc744e",
3 "created_at": "2024-03-04T20:08:16.097467+00:00",
4 "action": "entity.onboarding_requirements.status_updated",
5 "api_version": "2024-01-31",
6 "entity_id": "37156af0-fbf7-44f7-b375-42e4d98733e2",
7 "description": "entity_onboarding_requirements_status_updated",
8 "object": {
9 "id": "37156af0-fbf7-44f7-b375-42e4d98733e2"
10 },
11 "object_type": "entity",
12 "webhook_subscription_id": "c7f37127-44e5-494a-833a-21e60585f187"
13}

6.2. Get onboarding requirements

The entity ID received from the webhook can be used to check the progress of entity onboarding, by calling GET /onboarding_requirements:

1curl -X GET 'https://api.sandbox.monite.com/v1/onboarding_requirements' \
2 -H 'X-Monite-Version: 2024-01-31' \
3 -H 'X-Monite-Entity-Id: ENTITY_ID' \
4 -H 'Authorization: Bearer YOUR_PARTNER_TOKEN'

The response contains the information about the entity onboarding:

1{
2 "verification_status": "disabled",
3 "disabled_reason": "requirements.past_due",
4 "requirements_errors": [],
5 "verification_errors": [],
6 "requirements": {
7 "currently_due": [
8 "bank_account",
9 "entities.onboarding_data.business_profile.mcc",
10 "entities.organization.directors_provided",
11 "entities.phone",
12 "persons.representative.phone",
13 "persons.123e4567-e89b-12d3-a456-426614174000.first_name"
14 ],
15 "eventually_due": [
16 "bank_account",
17 "entities.onboarding_data.business_profile.mcc",
18 "entities.organization.directors_provided",
19 "entities.phone",
20 "persons.representative.phone",
21 "persons.123e4567-e89b-12d3-a456-426614174000.first_name"
22 ],
23 "current_deadline": null,
24 "pending_verification": []
25 }
26}

Some fields are explained below:

  • requirements - the list of required information that the entity needs to provide to finish the onboarding.
  • currently_due - the list of minimum fields required to keep the entity’s account enabled. This data must be provided by the current_deadline date.
  • current_deadline - date by which the fields in currently_due must be collected to keep the entity’s account enabled.
  • eventually_due - the list of fields that are not needed immediately, but will be needed at some point later.
  • business_profile.mcc - the merchant category code (MCC) of the entity.
  • persons.representative.phone - means that the phone number of the entity’s representative must be provided.
  • persons.123e4567-e89b-12d3-a456-426614174000.first_name - when a UUID is found in a field name, it means that a resource with that ID is missing some information. In this example, the first_name must be provided for the person with ID 123e4567-e89b-12d3-a456-426614174000.

Every time the entity provides some of the listed requirements, the onboarding_requirements.updated webhook is triggered.

Next steps

After a US-based entity is onboarded, it needs to verify its bank account. See Verifying bank accounts for ACH payments.