Onboard Merchants

 

Onboard Merchants with Custom Components

A Legal Entity API object represents a single person (in the case of sole proprietors), business, or a non-profit. They store the personal and business verification information (Know Your Customer) that we use to underwrite and protect your users against fraud.

Since some Legal Entity information can be considered Personal Identifiable Information (PII), Legal Entities should be created via Tokenization. Tokenization lets you avoid having to handle and process information like name, address, and social security number in your own systems.
Note

A merchant's Payment capability will be disabled if they do not complete KYC and provide settlement information within 30 days of processing a Payment or before reaching $100,000 in processing.

If a merchant still does not complete KYC and provide settlement information within 30 days of their account disablement, their account will be refunded.

See our Enable Merchants article for more information.

Create a Legal Entity with Custom Components

When creating a Legal Entity, it's important to remember that not all details need to be provided at once. To demonstrate this powerful use case, start by creating a Legal Entity with a POST/ legal_entities request containing just the country parameter.
Copy
Copied
{
  "country": "US"
}
This will return a legal_entity_id (be sure to keep this handy -- you'll likely want to store these IDs to your own database), as well as other information that still needs filling. As you can see, you'll need to fill out quite a bit of information. You can now capture this information using tokenization.

Invoke the WePay Helper Javascript Library in your platform's front-end where you'll collect additional Legal Entity information:
Copy
Copied
WePay.tokens.create({
  "resource": "legal_entities",
    "legal_entities": {
      "controller": {
        "email": "test1@test.com",
        "name": {
          "first": "foo",
          "middle": "t",
          "last": "bar"
          },
        "is_beneficial_owner": true,
        "email_is_verified": true
		},
	  "terms_of_service": {
	    "acceptance_time": 1551980186,   // Send real merchant TOS acceptance time
	    "original_ip": "8.8.8.8"          // Send real merchant original IP
		}
	  }
})

If you are onboarding a Government Entity or a Publicly Traded Company (including subsidiaries), then your request will look like this:

Copy
Copied
WePay.tokens.create({
  "resource": "legal_entities",
    "legal_entities": {
      "account_controller": {
        "email": "test1@test.com",
        "name": {
          "first": "foo",
          "middle": "t",
          "last": "bar"
          },
        "email_is_verified": true
		},
	  "terms_of_service": {
	    "acceptance_time": 1551980186,   // Send real merchant TOS acceptance time
	    "original_ip": "8.8.8.8"          // Send real merchant original IP
		}
	  }
})

The response for any successful Legal Entities token create call will contain a Legal Entity token which looks like this:

legal_entities-660420e3-ad2b-4ebe-914c-4a7b55d01dd4

You can now update the existing Legal Entity with this new information using a POST /legal_entites/id request:
Copy
Copied
{
    "token": {
        "id": "legal_entities-660420e3-ad2b-4ebe-914c-4a7b55d01dd4"
    }
}

Tokens have a time-to-live (TTL) of 30 minutes, so the API request must be made in that timeframe in order to successfully add the tokenized information.

The JS example above assumes you've verified the merchant's email on your platform. If you haven't, it is your responsibility to do so, and until then, the email_is_verified parameter should be set to false. When sending the Legal Entity entity_name, this should not include the "Doing Business As" (DBA) name, but the legal name on record. A merchant's DBA can be included on the Account resource, if applicable. All the parameters available in the tokenization JS can also be found in the Legal Entity API.
Note
The following values are not accepted for the address.region parameter in entity or controller information:
  • PR
  • VI
  • AA
  • AE
  • AP
The above example collected the minimum Legal Entity information needed upfront to enable Payments. Next, you'll create an Account with the minimum Account information needed to enable Payments.

Define Beneficial Owner

For all merchants except Government Entities and Publicly Traded Companies (including subsidiaries), the controller must be defined, regardless of if they are a beneficial owner. A controller is an individual with significant responsibility to control or manage the Legal Entity (VP type role, or above, so you can use C-Suite roles and founders). A beneficial owner is someone who owns 25% or more of the organization.

Learn more about the definition and KYC requirements for a controller and a beneficial owner.
Note

It is important that the defined controller is the actual controller of the organization since they will be required to provide their own personal KYC as the controller during onboarding.

If the controller is not a beneficial owner, you would need to set controller.is_beneficial_owner to false, define Additional Representatives, and identify a beneficial owner as one of the additional representatives. Below are the rules for identifying who is a beneficial owner and who isn't.
  1. If a controller IS a beneficial owner, then you can have, at max, 3 other Additional Representatives.
  2. If a controller IS NOT a beneficial owner, then you can have, at max, 4 Additional Representatives.
  3. If a controller IS NOT a beneficial owner, it's not guaranteed that you will use any and all additional representatives, because an additional representative must have greater than or equal to 25% of the business.

In addition to collecting beneficial owner information, any change made to the controller or beneficial owners' (additional representatives) personal details requires attestation from the Controller, as shown below.

By clicking "Submit," you hereby certify, to the best of your knowledge, that the information provided above is complete and correct.

Learn more about attestation here.Your UI must also provide the controller with a review of the details submitted by other entity beneficial owners. The date_of_birth and either social_security_number for US or social_insurance_number for Canada, should not be displayed. Instead, use a GET /legal_entities/id call to lookup the boolean values for date_of_birth_is_present and either social_security_number_is_present or social_insurance_number_is_present.

Create an Account with Custom Components

This step creates a merchant Account in our system, not a merchant account with a bank. Logically, a Legal Entity is the parent of the Account and can own multiple Accounts, while an Account can have at most one Legal Entity.

Once you have a Legal Entity, you'll need an Account to begin processing payments. An Account is an approximate representation of what your platform would consider a merchant account, containing specific information about the shop/business/person directly processing payments, and the Account ID will be the API owner of Payments and other transactions. Accounts will not contain any sensitive information requiring tokenization.

First, let's start by creating an Account using the Legal Entity ID from earlier, in addition to the minimum required data to enable Payments.
Copy
Copied
{
  "legal_entity_id": "98e4134b-b148-41ad-8079-71232a773d70",
  "name": "Fo",
  "description": "This is Foo's location on B street",
  "industry": {
    "merchant_category_code": "7333"
  },
  "statement_description": "Foo Shop"
}
Note
Be sure to include a useful value for the statement_description parameter. This value is what will show up on payer's card/bank statements, and setting a clear, brief description will help them identify charges. Typically, receiving banks will display 14-20 characters, so be sure to include the most useful information in those first 14 characters. When payers are able to identify charges on their statements, chargeback rates are reduced.

Pending payments (including auth requests) will appear on card statements with WPY\*statement_description, but for AmEx it may show "WePay" instead of the description if the merchant has not completed KYC.
If the merchant has a DBA ("Doing Business As"), then use that title in the name parameter. You'll also want to be precise with the name and description of the Merchant's account, as it's possible for a single Legal Entity to be linked to multiple Accounts. All available parameters can be found in the Accounts API.

Like the Legal Entities object, you'll receive an Account with minimal information populated. There is, of course, more to populate. See a full list of account-level rBits to include when you create an Account with POST/ accounts. This helps with improving the accuracy of WePay's risk solution, reducing manual review times and documentation requests from Merchants.

You'll also notice payout and incoming_payments -- let's leave them blank for now, we'll fill them out in the Payout Merchants section.

As you develop a UI for merchants to submit required Legal Entity and Account information, reference our CIP and KYC Certification to ensure regulatory compliance.