Enable Merchants

 

At this point we have created a Legal Entity and an Account to represent your user with enough information to begin processing Payments. The remaining required information can be submitted in a progressive fashion, allowing your users time to collect the details. To complete progressive onboarding, Account capabilities will be enabled by fulfilling Legal Entity verifications.

If you selected pre-built components to onboard merchants, then your users will complete this process through the WePay-hosted merchant center. If you selected custom components to onboard merchants, then you can choose between the KYC iFrame and custom components.

Required information to enable merchants depends on the type of business (sole proprietor vs LLC vs corporation) and country, so we've provided an endpoint which allows you to look up exactly what is needed for each resource:

Fulfilled capabilities and verifications are the gateways to merchants receiving Payments and Payouts, and the above endpoints are great sanity checks on our requirements for any given merchant. Beyond ad-hoc sanity checks, you'll automate the collection of required details to ensure success and seamless service for merchants on your platform.

As part of the integration, you'll be required to certify both the legal and KYC aspects of onboarding merchants. Once you're finished building, read through the following docs to ensure compliance:


Interface with Capabilities and Verifications

Capabilities

Today, we support two capabilities that you must enable for merchants: accepting Payments and receiving Payouts of funds to their bank account. Note that there is also a Terminals capability, only applicable to platforms leveraging the Card Present solution.

If you've followed this guide so far, you'll notice that certain information is still required when you lookup an account's capabilities through GET /accounts/{id}/capabilities request. The response will show that Payments are enabled, but Payouts are not:
  • enabled: A boolean indication of whether the capability is enabled. Note that a true response does not mean the account is permanently enabled, or that other information will not become a requirement in the future.
  • upcoming_issues: A UNIX epoch timestamp of when upcoming issues must be fulfilled to avoid enablement becoming false.
  • current_issues: If applicable, this provides further explanation of why a capability is not enabled.

Use this endpoint to identify the information that still needs to be provided by your merchants.

Verifications
In addition, make a call to the equivalent for Legal Entities: GET /legal_entities/{id}/verifications. This request will lookup any additional documentation or information that we need in order to properly underwrite and verify a Legal Entity.

Expanded: False
If you'd like to lookup capabilities and verifications, you can use the query parameter is_expanded, and set it to false.
  • GET /accounts/{id}/capabilities?is_expanded=false
  • GET /legal_entities/{id}/verifications?is_expanded=false

This will return a response that simply shows verification and capability status, without the full details:

Copy
Copied
{
  "payments": {
    "enabled": true
  },
  "payouts": {
    "enabled": false
  },
  "terminals": {
    "enabled": false
  },
  "id": null,
  "resource": "capabilities",
  "path": "/accounts/{id}/capabilities",
  "owner": {
    "id": "id",
    "resource": "accounts",
    "path": "/accounts/{id}"
  },
  "api_version": "3.0"
}

Provide Required Details for Enablement

The scope of required details to enable merchants involves three areas of the API:

  1. Enable payments on the capabilities endpoint
  2. Enable payouts on the capabilities endpoint
  3. Verify merchants on the verifications endpoint

If merchants do not provide any given piece required information by the deadline (outlined below), then capabilities will be disabled. If merchants still do not provide the missing required information by the second deadline, then any balance will be refunded to payers and the account will be closed.

Enable Payments

To enable the Payment capability for merchants, you'll need to provide certain information about the Legal Entity and Account in a timely manner (specific deadlines are defined below). The API is designed to accept this information as you go, and it isn't necessary to provide this information all at once.

1. Immediate requirements
This information must be provided before a merchant can process their first Payment.
DetailsParameters
Controller's email address *legal_entity.controller.email
Entity's country of operationlegal_entity.country
Merchant's TOS acceptance timelegal_entity.terms_of_service.acceptance_time
The IP address from which the merchant accepted TOSlegal_entity.terms_of_service.original_ip
Annual Sales Volume (if Upfront Underwriting is enabled)legal_entity.annual_sales_volume
Annual Credit Card Volume (if Upfront Underwriting is enabled)legal_entity.annual_credit_card_volume
Average Transaction Size (if Upfront Underwriting is enabled)legal_entity.average_ticket_size
The account nameaccount.name
The account descriptionaccount.description
Merchant Category Codeaccount.industry.merchant_category_code
* Government Entities and Publicly Traded Companies (including subsidiaries) will use the account_controller structure, so they should send legal_entity.account_controller.email. All other legal forms and private companies will use controller, as seen in the table above. We now require the Merchant Category Code (MCC) immediately to enable payments.
Upfront Underwriting

Upfront underwriting is the process by which WePay evaluates the potential risk exposure of a business by gathering additional information from the merchant to calculate and predict the chargeback rate, refund rate, and non-delivery risk of goods and services in addition to calculating our dollar value of credit exposure. This is an upfront assessment of our risk exposure before enabling payment and payout capabilities. Underwriting only occurs once. After a merchant is underwritten, any updates will not result in another underwriting. Payment processing capabilities will default to disabled until upfront underwriting is complete.

If Upfront Underwriting is enabled, the process triggers once the merchant provides their annual sales volume, annual credit card volume, and average transaction size. To check the status of upfront underwriting, call the GET/accounts/id/capabilities endpoint. If underwriting is still in review, payments.current_issues.issue_type will have a value ofunderwriting_not_completed.

To learn more, please contact your integration team or technical account manager for more information.

danger

Until the above requirements are met, the Legal Entity and Account will not be able to accept Payments at all, and you will receive API errors.

2. Requirements due 14 days after 1st payment, or $100,000 USD processed, whichever comes first
In order to continue processing Payments, the controller's email address must be verified. It is your responsibility, as the platform, to verify the email address provided to you from the Legal Entity's controller.
DetailsParameter(s)
The controller must verify their email address.legal_entity.controller.email_is_verified*
*Government Entities and Publicly Traded Companies (including subsidiaries) will use the account_controller structure. All other legal forms will use controller.
Deadline

If requirements are not met by 14 days after first Payment, or $100,000 USD, we will disable incoming Payments for the Legal Entity (and all Accounts owned by the Legal Entity). After 30 days total (16 days after the original 14 days), we will refund payments to payers and close the account if the email address has still not been verified.

3. Requirements due 30 days after 1st payment
The merchant will need to provide additional information (if not already provided) depending on the Legal Form in order to continue accepting Payments.
Click for Legal Form: Individual requirements...
DetailsParameters
Country-specific legal entity type
  • legal_entity.entity_country_info.us.legal_form
  • legal_entity.entity_country_info.ca.legal_form

NOTE: The value here should be individual
Controller's name
  • legal_entity.controller.name
The controller's residential addresslegal_entity.controller.address
The controller's personal phone numberlegal_entity.controller.phone
The controller's date of birthlegal_entity.controller.date_of_birth
The individual's country-specific identification number
  • legal_entity.controller.personal_country_info.us.social_security_number
  • legal_entity.controller.personal_country_info.ca.social_insurance_number (Optional for merchants in Canada)
Whether the controller is a beneficial owner (owns 25% or more of the entity)legal_entity.controller.is_beneficial_owner

NOTE: The value here should be true, and there should not be other beneficial owners.

Click for Legal Forms: Sole Proprietor requirements...
DetailsParameters
Country-specific legal entity type
  • legal_entity.entity_country_info.us.legal_form
  • legal_entity.entity_country_info.ca.legal_form
NOTE: The value here should be sole_proprietor
Country-specific entity identification number
  • legal_entity.entity_country_info.us.employer_identification_number
  • legal_entity.entity_country_info.ca.business_number
Note: In the United States, merchant that chooses entity type 'sole proprietor' must be given a choice to enter an EIN with the last four of their Social Security Number or no EIN with their full Social Security Number.
The entity descriptionlegal_entity.description
The entity's phone numberlegal_entity.phone
The entity's primary web-presencelegal_entity.primary_url
The entity namelegal_entity.entity_name
Controller's namelegal_entity.controller.name
The controller's residential addresslegal_entity.controller.address
The controller's personal phone numberlegal_entity.controller.phone
The controller's date of birthlegal_entity.controller.date_of_birth
The controller's country-specific identification number
  • legal_entity.controller.personal_country_info.us.social_security_number
  • legal_entity.controller.personal_country_info.ca.social_insurance_number (Must be optional for merchants in Canada)
Whether the controller is a beneficial owner (owns 25% or more of the entity)legal_entity.controller.is_beneficial_owner
Additional representatives who are beneficial owners (own 25% or more of the entity)
  • legal_entity.additional_representatives.representative_X.name
  • legal_entity.additional_representatives.representative_X.address
  • legal_entity.additional_representatives.representative_X.phone
  • legal_entity.additional_representatives.representative_X.date_of_birth
  • legal_entity.additional_representatives.representative_X.personal_country_info.US.social_security_number
  • legal_entity.additional_representatives.representative_X.personal_country_info.CA.social_insurance_number (Must be optional for merchants in Canada)

Click for Legal Form: Corporation, Limited Liability Company, Non-Profit, Partnership, or Government Entity requirements...
DetailsParameters
Country-specific legal entity type
  • legal_entity.entity_country_info.us.legal_form
  • legal_entity.entity_country_info.ca.legal_form
Country-specific entity identification number
  • legal_entity.country_info.us.employer_identification_number
  • legal_entity.country_info.ca.business number
The entity descriptionlegal_entity.description
The entity's phone numberlegal_entity.phone
The entity's primary web-presencelegal_entity.primary_url
The entity namelegal_entity.entity_name
Controller's namelegal_entity.controller.name

Note: Government Entities and Publicly Traded Companies (including subsidiaries) will use

account_controller.name
The controller's residential addresslegal_entity.controller.address

Note: Government Entities and Publicly Traded Companies (including subsidiaries) will use

legal_entity.account_controller.address
The controller's personal phone numberlegal_entity.controller.phone

Note: Government Entities and Publicly Traded Companies (including subsidiaries) will use

legal_entity.account_controller.phone
The controller's date of birthlegal_entity.controller.date_of_birth

Note: This data must not be collected from account controllers of Government Entities and Publicly Traded Companies (including subsidiaries).

The controller's country-specific identification number
  • legal_entity.controller.country_info.us.social_security_number
  • legal_entity.controller.country_info.ca.social_insurance_number

    (Must be optional for merchants in Canada)

Note: This data must not be collected from account controllers of Government Entities and Publicly Traded Companies (including subsidiaries).

Whether the controller is a beneficial owner (owns 25% or more of the entity)legal_entity.controller.is_beneficial_owner

Note: This data is not applicable to account controllers of Government Entities or Publicly Traded Companies (including subsidiaries).

Additional representatives who are beneficial owners (own 25% or more of the entity)

*Not required for Non-Profits upon status verification*
  • legal_entity.additional_representatives.representative_X.name
  • legal_entity.additional_representatives.representative_X.address
  • legal_entity.additional_representatives.representative_X.phone
  • legal_entity.additional_representatives.representative_X.date_of_birth
  • legal_entity.additional_representatives.representative_X.personal_country_info.US.social_security_number
  • legal_entity.additional_representatives.representative_X.personal_country_info.CA.social_insurance_number

Note: This data is not applicable to account controllers of Government Entities and Publicly Traded Companies (including subsidiaries).

Whether the controller is a beneficial owner (owns 25% or more of the entity)legal_entity.controller.is_beneficial_owner

Note: This data is not applicable to account controllers of Government Entities and Publicly Traded Companies (including subsidiaries).


Click for Publicly Traded Company (including subsidiary) requirements...
DetailsParameters
Indicate whether the merchant is traded in any of the following:
  • New York Stock Exchange
  • American Stock Exchange
  • NASDAQ as a NASDAQ National Market Security
Note: Subsidiaries should pass false for this field.
legal_entity.public_ownership.is_publicly_traded
Subsidiaries only: Indicate whether the merchant is majority owned (i.e. 51% or greater) U.S. by a company publicly traded on one of the three exchanges listed above:legal_entity.public_ownership.is_subsidiary
Subsidiaries only: Parent company legal namelegal_entity.public_ownership.parent_company_name
Ticker symbol for relevant exchange(s):
  • New York Stock Exchange
  • American Stock Exchange
  • NASDAQ as a NASDAQ National Market Security
Note: Subsidiaries should pass the ticker symbol of their parent company.
legal_entity.public_ownership.traded_exchanges.NYSE/AMEX/NASDAQ.symbol
Deadline

If the necessary information has not been provided 30 days after first Payment, the capability will become disabled on the Account. If the information has still not been provided 60 days after first Payment (30 days after the capability is disabled), then we will refund any balance and close the Account.

Enable Payouts

The Payouts capability allows merchants to send funds they have collected over to their linked bank account Payout Method.

Just like the Payments capability, there is required information which must be submitted to enable the Payouts capability for an Account. Some of these requirements are immediate, and some allow progressive submission with a deadline.

1. Immediate requirements
These requirements must be met before the merchant is able to receive their first Payout from their WePay Account.
DetailsParametersNotes
All requirements associated with enabling the payments capability.See Enable PaymentsThere isn't a trailing time component as with enabling payments, so any missing information must be submitted at the time you want payouts enabled, even if the deadline for payments has not been reached.
Country of entity's formationentity_country_info.
country_of_formation
Required for all Legal Entities. (except with legal form individual).
Year of entity's formationentity_country_info.
year_of_formation
Required for all Legal Entities (except with legal form individual).
Sanctioned countries of operationentity_country_info.
operates_in_sanctioned_countries
Only applicable if your platform's business model is considered SMB. Check with your integration team if you are not sure.

The question to your merchant must read exactly as: "Do you have any operations, vendors, suppliers or sell goods or services in, or support other activities directly or indirectly relating to Cuba, Iran, Syria, North Korea or Crimea?" to which the merchant must select either "Yes" or "No" in response. If the merchant selects "Yes," they must then be able to select all 5 countries which apply to them.

If your merchant has not answered this question, leave the value as null. If the merchant has answered "no," then send an empty array: [].
Non-domestic beneficiariessignificant_beneficiaries.
non_domestic_location_beneficiaries

Note: Although this parameter is housed in the significant_beneficiaries structure, this is required for all non-domestic beneficiaries, even if they receive or control less than 10% of a Legal Entity's funds.
Only applicable if your platform's business model is considered fundraising. Check with your integration team if you are not sure.

We recommend phrasing the question to your merchant as: "Does your Business/Organization operate in or serve beneficiaries in non domestic locations?" to which the merchant can respond with either "Yes" or "No." If they respond with "No," then the merchant must be able to select all countries which apply.
danger

Until the above requirements are met, the merchant will not be able to receive Payouts at all.

2. Requirements due 30 days after 1st payment
DetailsParameters
Legal entity physical address of operationlegal_entity.address
Controller's job titlelegal_entity.controller.job_title
Note: This data is not applicable to account controllers of Government Entities or Publicly Traded Companies (including subsidiaries).
Set a payout method
  • account.payout.currencies.usd.payout_method_id
  • account.payout.currencies.cad.payout_method_id
Define a payout frequency
  • account.payout.currencies.usd.period
  • account.payout.currencies.cad.period
Deadline

If Payouts have not been enabled 30 days after first Payment, then incoming Payments will be disabled on the Account. If Payouts have still not been enabled 60 days after first Payment (30 days after disabled Payments), then we will issue refunds and close the Account.

Once all requirements for the Payouts capability are met, a Payout will automatically be sent out to the Payout Method. Future Payouts will follow the defined Payout frequency.

Verify Merchants

In most cases, we will be able to verify merchants in the United States automatically once Payments and Payouts have been enabled. Leveraging the verifications endpoint as described earlier will keep you informed on the merchant's status, and any additional information that we may require in some edge cases, and for merchants in Canada.

The following verification flows should be built out in order to satisfy any additional requests for information, but they will not be applicable to all merchants. If/when one of these flows does become applicable to a merchant, deadlines for completing requested action items will be applicable, and will result in the Account being refunded if not completed on time. Be sure to code for the following flows:

  1. Resubmit Information
  2. Upload Verifications and Outreaches
  3. Verify High Volume NGOs and Charities
  4. Update Personal Information
Remember to follow the Legal Certification and CIP & KYC Certification to build your merchant-facing UIs.

Resubmit Information

If submitted information cannot be verified, we may request that it be re-submitted. If this happens, we will reset the applicable field(s), which will null out the corresponding API fields and return them in the errant_fields current issue or upcoming issue. Lookup current and upcoming issues in the GET /legal_entities/{id}/verifications endpoint.

Verifications Errant Field Current Issue Reasons

Errant Field ReasonReason
includes_dbaBusiness Legal Name should not include Doing Business As (DBA); it should be the legal name on any licensing or tax paperwork.
does_not_match_provided_docThe value of the target does not match provided documentation. Advise the merchant to provide documentation that matches the requested field.
does_not_match_government_sourcesThe value of the target does not match government verification sources. Advise the merchant to provide correct government information.
invalid_urlWe cannot verify the URL. The merchant should double check their website URL and submit it again.
Deadline

If a merchant must re-submit information, resubmission must be completed within 30 days of the request. If information is not resubmitted within 30 days, then the Payments capability will become disabled. If information still has not been resubmitted 60 days after the initial request (30 days after disabled payments), then any balance will be refunded, and the Account will be closed.

Upload Verifications and Outreaches

Some rare cases require the merchant to upload supporting documentation (note that these cases are more frequent for merchants in Canada). Although these cases are not frequent, your platform must be able to programmatically handle requests that do come through. We may require documentation to either:
  • complete Legal Entity Verifications
  • enhance Account fraud protection
By default, documentation requests can be identified as the additional_documents_required issue type. Please note that this parameter does not specify the type of documentation that is required, or which individual it is required for.

To get specifics on what type(s) of documents are required, work with your integration team or technical account manager who can configure your WePay app to use the method described below:

Listen for both of these events by subscribing to the legal_entities.verifications.updated Notification, and examine the payload's controller, additional_representatives and entity_verification current_issues for:
  • issue_type.identity_verification (Legal Entity Verifications)
  • issue_type.risk_outreach (Account fraud protection)

Example payload:

Copy
Copied
{
  "id": "{notification-id}",
  "resource": "notifications",
  "path": "/notifications/{id}",
  "owner": {
    "id": "{app-id}",
    "resource": "applications",
    "path": null
  },
  "topic": "legal_entities.verifications.updated",
  "event_time": 1601937976,
  "payload": {
    "entity_verification": {
      "verified": false,
      "current_issues": [
        {
          "target": {
            "resource": "verifications",
            "id": null,
            "path": "/legal_entities/{id}/verifications"
          },
          "issue_type": "identity_verification",
          "identity_verification": {
            "message": "We need to verify your name.",
            "requested_documents": [
              "certified_copy_of_court_order"
              ],
            "path": "entity_verification.documents"
          }
        }
      ],
      "documents": []
    },
    "controller": {
      "personal_verification": {
        "verified": false,
        "current_issues": [
          {
            "target": {
              "resource": "legal_entities",
              "id": "{legal_entities-id}",
              "path": "/legal_entities/{id}"
            },
            "issue_type": "risk_outreach",
            "risk_outreach": {
              "message": null,
              "requested_documents": [
                "passport"
                ],
              "path": "controller.personal_verification.documents"
            }
          }
        ],
        "documents": []
      }
    },
    "additional_representatives": {
      "representative_0": {
        "personal_verification": {
          "verified": true
        }
      }
    },
    "id": null,
    "resource": "verifications",
    "path": "/legal_entities/{id}/verifications",
    "owner": {
      "id": "{legal_entities-id}",
      "resource": "legal_entities",
      "path": "/legal_entities/{id}"
    },
    "api_version": "3.0"
  },
  "api_version": "3.0"
}

Note that it is possible for Legal Entity Verifications and Account fraud protection documentation to be required simultaneously from a merchant. Additionally, it is possible for multiple documents to be required from the controller, the entity, or an additional representative.

Upon receipt of the Notification, you will be able to identify which documents are required, and who should provide it. For both the identity_verification and risk_outreach objects, the requested_documents array will provide a list of document types which must be uploaded, and the path will identify where the document ID should go in the update request.

Next, if you own end-user emails, then you must notify the merchant that documentation is required according to the "Supporting documentation is required for Legal Entity Verifications" scenario in our Notifications guide.
Deadline
identity_verification will result in immediate disablement of the Payouts Capability for the Account. If documents have not been submitted 30 days after we have requested them, then the Payments Capability will be disabled on the Account. If documents have still not been provided 60 days after they were requested (30 days after disabled payments), then we will issue refunds to the payers and close the account.risk_outreach will not result in any Capability disablement, but our risk team will manually hold Payouts until the requirement is satisfied. Additionally, any applicable Payments may need to be refunded if the requirement cannot be satisfied.
Provide a UI for your merchants to upload verification documents.
This UI should provide a list of the currently required documents for the merchant, from which the user will identify the type they are uploading. Note that the message response parameter can be null, so your UI should be able to handle that scenario. To handle the case that the same document type is required for two or more paths (i.e. the controller's personal verification and an addtional representative's personal verification), your UI should also allow the user to select the owner of the document at the time of upload.

The code for your UI could function something like this:

htmljs
Copy
Copied
<body>
  <h2 style="font-family: Arial; color: slategray">KYC Document Upload</h2>
  <select style="color: #4B4746" id="ddlContType">
    <option style="color: #4B4746">-- Select --</option>
    <option style="color: #4B4746" id="input1" value="affiliation">affiliation</option>
    <option style="color: #4B4746" id="input2" value="bankruptcy_trustee">bankruptcy_trustee</option>
    <option style="color: #4B4746" id="input3" value="certificate_of_association">certificate_of_association</option>
    <option style="color: #4B4746" id="input4" value="companies_house">companies_house</option>
    <option style="color: #4B4746" id="input5" value="current_local_tax_bill">current_local_tax_bill</option>
    <option style="color: #4B4746" id="input6" value="electoral_register_entry">electoral_register_entry</option>
    <option style="color: #4B4746" id="input7" value="evidence_of_authority">evidence_of_authority</option>
    <option style="color: #4B4746" id="input8" value="evidence_of_name_change">evidence_of_name_change</option>
    <option style="color: #4B4746" id="input9" value="filed_audited_accounts">filed_audited_accounts</option>
    <option style="color: #4B4746" id="input10" value="insurance_bill">insurance_bill</option>
    <option style="color: #4B4746" id="input11" value="marriage_certificate">marriage_certificate</option>
    <option style="color: #4B4746" id="input12" value="partnership_agreement">partnership_agreement</option>
    <option style="color: #4B4746" id="input13" value="secretary_of_state">secretary_of_state</option>
    <option style="color: #4B4746" id="input14" value="vehicle_registration">vehicle_registration</option>
  </select>
  <input style="color: #4B4746" type="file" id="filegoeshere">
  <br><br>
  <button style="color: #4B4746" onclick="submit()">Submit</button>
  <div id="token"></div>
  <script src="https://cdn.wepay.com/wepay.min.js"></script>
</body>
Copy
Copied
var app_id = "{your-app-id}"; // your platform's app ID
var legal_entity_id = "{legal-entity-id}"; // Get this from user's login
var environment = "stage";
var api_version = "3.0";
WePay.configure(environment, app_id, api_version);
var error = WePay.configure("stage", app_id, api_version);
if (error) {
  console.log(error);
}

function submit() {
  var inputs = document.getElementById("filegoeshere");
  if (inputs.files !== undefined && inputs.files.length > 0) {
    var file = inputs.files[0];
  }

  var options = document.getElementById("ddlContType");
  {
    var type = options.value;
  }

  var body = {
    type: type,
    legal_entity_id: legal_entity_id,
    file: file
  };

  var headers = {};

  var node = document.createElement("div");
  var resp = WePay.documents.create(body, headers, function (response) {
    node.innerHTML = JSON.stringify(response);
    document.getElementById("token").appendChild(node);
  });
}
Find more details in our Create A User Interface guide.Once the merchant has provided documents, grab the document ID(s) from the console and submit them using a POST /legal_entities/{id}/verifications request like this:
Copy
Copied
curl -X POST \
  --url 'https://api.wepay.com/legal_entities/{id}/verifications' \
  -H 'Accept: application/json'\
  -H 'App-Id: {app-id}'\
  -H 'App-Token: {app-token}'\
  -H 'Api-Version: 3.0'\
  -H 'Content-Type: application/json' \
  --data-raw '{
  "controller": {
    "personal_verification": {
      "documents": [
        "{document-id}"
      ]
    }
  }
}'
Note

Documents have a time-to-live (TTL) of 24 hours, after which, the document's ID will become invalid, and the merchant will have to re-upload their documentation.

Building out the UI and back end to upload documents is vital to ensuring a seamless progressive onboarding experience for your merchants. If we require additional documentation in order to verify a merchant for continued processing, an easy-to-navigate method for merchants to provide the needed documents expedites the process.

Verify High Volume NGOs and Charities

When an entity has the legal form of either unincorporated_association or nonprofit_corporation, and processes $1.2 million or more in a rolling 12-month period, they are considered high volume and we require additional information. If the legal entity has multiple Accounts, then the volume threshold ($1.2 Million) is calculated across all of those Accounts.

The trigger_status field of the legal_entities.tpv_threshold_reached Notification will fire at the respective Total Processing Time (TPV) triggers of $500K, $1M, and $1.2M. Note that there will be no changes to your capabilities at the first_trigger and second_trigger.

We recommend sending emails (samples here), once receiving Notifications from WePay:
  1. first_trigger: Account has processed $500,000.00 in a rolling 12-month window. Platform to email merchant, providing context for additional verification, and allow them to submit information.
  2. second_trigger: Account has processed $1,000,000.00 in a rolling 12-month window. Platform to email merchant, reiterating the required verification & that they are approaching the threshold, and allow them to submit information.
  3. third_trigger: Account has processed $1,200,000.00 in a rolling 12-month window for the first time. Platform to email merchant, indicating that additional verification is now required, and direct them to your platform for submission.
At the $1.2M threshold (3), an additional notiification will be sent: The payouts.current_issues.errant_fields block of accounts.capabilities.updated Notification will specify the below parameters being needed. If information isn't provided by the $1.2M threshold, payout capabilities are disabled. If, after 30 days, the information isn't provided, incoming payments will be disabled.

The information is all provided to the Legal Entity resource. Note that once the additional information is provided once, it will not need to be provided again.

DetailParameter(s)Notes
Significant beneficiaries' affiliatessignificant_beneficiaries.affiliationsSpecifies a list of affiliated Non Profit organizations to merchants. Multiple affiliations, countries of affiliations, and association types are allowed.
Significant beneficiaries' locationsignificant_beneficiaries.geographiesA significant beneficiary is any person or entity who receives or controls 10% or more of the funds being collected. For geographies, all values are allowed, and if specifying international, multiple countries allowed.
Significant beneficiaries' entity typesignificant_beneficiaries.entitiesSpecifies the type of entities of significant beneficiaries - multiple selections allowed.
Significant donors' entity typesignificant_donorsA significant donor is any person or entity who contributes 10% or more of the organization's total volume.
Entity Purpose or Ideologyentity_purpose_or_ideologySpecifies the purpose or ideology of the organization.
Entity Source and Use of Fundssource_and_use_of_fundsSpecifies the information about the source and use of organization's funds.
Indicator if Entity has significant wealth contributorshas_significant_wealth_contributorsIndicates [True/False] if there are possible significant wealth contributors to the organization. A significant wealth contributor is any person or entity who contributes 10% or more to the organization's funding, also known as investors. Note: This field is only required if the entity_purpose_or_ideology is Family Foundation.
Significant wealth contributorssignificant_wealth_contributorsInformation of up to 10 significant wealth contributors to the organization. A significant wealth contributor is any person or entity who contributes 10% or more to the organization's funding, also known as investors. Note: This field is only required if the entity_purpose_or_ideology is Family Foundation.

Here is a preview of how your platform can use the API endpoints above to collect information from high volume NGO's and Charities:

An example of how WePay has implemented the TPV questions for high volume entities.
An example of how WePay has implemented the TPV questions for high volume entities.
An example of how WePay has implemented the TPV questions for high volume entities.
An example of how WePay has implemented the TPV questions for high volume entities.
An example of how WePay has implemented the upfront questions for high volume entities
An example of how WePay has implemented the upfront questions for high volume entities
An example of how WePay has implemented the upfront questions for high volume entities
An example of how WePay has implemented the upfront questions for high volume entities

Update Personal Information

The individuals associated with a Legal Entity and Account (controllers & additional representatives) may experience a change in their personal information (i.e. phone number, email, address, etc.). Additionally, individuals may leave or join the business, and their information should be removed or added via the API. Here are a few guidelines on how to handle these changes:

  • Personal information can be updated at any time, so long as attestation is presented to the user before the update is submitted. See the legal certification for implementation requirements related to these kinds of information updates.
  • Updates will trigger re-verification on our end. Re-triggering verification will put an Account's Payout capability in "enabled": "false" until verification is complete, and we may require supporting documentation.
    • Important: If a merchant is actively processing and needs to update information, we encourage you to notify them that payouts will be paused until the updated information is verified on our end.
Note

Any changes to the business's (Legal Entity in the API) name or EIN should not be permitted and would require a new Legal Entity.


Block Account Capabilities

This feature provides a layer of control to you, the platform. Use cases may arise where you want to block a merchant from processing payments or receiving payouts, and the Account Block feature allows you to do this. For instance, if a merchant is delinquent in paying their fees to your platform, their processing can be disabled without completely shutting down their account with us.

It is the platform's responsibility to monitor these blocks and notify merchants as needed. If an account is blocked and reaches a deadline listed above, we will attempt to refund and close the account.

Note
This feature is currently restricted, requiring our permission to leverage. If your platform has a use for blocking accounts, work with your account manager or integration team. Note that this feature is also currently experimental.