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 throughGET /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 atrue
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.
VerificationsIn 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:
{
"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:
- Enable payments on the capabilities endpoint
- Enable payouts on the capabilities endpoint
- 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 requirementsThis information must be provided before a merchant can process their first Payment.
Details | Parameters |
---|---|
Controller's email address * | legal_entity.controller.email |
Entity's country of operation | legal_entity.country |
Merchant's TOS acceptance time | legal_entity.terms_of_service.acceptance_time |
The IP address from which the merchant accepted TOS | legal_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 name | account.name |
The account description | account.description |
Merchant Category Code | account.industry.merchant_category_code |
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 theGET/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.
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.
Details | Parameter(s) |
---|---|
The controller must verify their email address. | legal_entity.controller.email_is_verified * |
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.
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...
Details | Parameters |
---|---|
Country-specific legal entity type |
NOTE: The value here should be individual |
Controller's name |
|
The controller's residential address | legal_entity.controller.address |
The controller's personal phone number | legal_entity.controller.phone |
The controller's date of birth | legal_entity.controller.date_of_birth |
The individual's country-specific identification number |
|
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...
Details | Parameters |
---|---|
Country-specific legal entity type |
sole_proprietor |
Country-specific entity identification number |
|
The entity description | legal_entity.description |
The entity's phone number | legal_entity.phone |
The entity's primary web-presence | legal_entity.primary_url |
The entity name | legal_entity.entity_name |
Controller's name | legal_entity.controller.name |
The controller's residential address | legal_entity.controller.address |
The controller's personal phone number | legal_entity.controller.phone |
The controller's date of birth | legal_entity.controller.date_of_birth |
The controller's country-specific identification number |
|
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) |
|
Click for Legal Form: Corporation, Limited Liability Company, Non-Profit, Partnership, or Government Entity requirements...
Details | Parameters |
---|---|
Country-specific legal entity type |
|
Country-specific entity identification number |
|
The entity description | legal_entity.description |
The entity's phone number | legal_entity.phone |
The entity's primary web-presence | legal_entity.primary_url |
The entity name | legal_entity.entity_name |
Controller's name | legal_entity.controller.name Note: Government Entities and Publicly Traded Companies (including subsidiaries) will use account_controller.name |
The controller's residential address | legal_entity.controller.address Note: Government Entities and Publicly Traded Companies (including subsidiaries) will use legal_entity.account_controller.address |
The controller's personal phone number | legal_entity.controller.phone Note: Government Entities and Publicly Traded Companies (including subsidiaries) will use legal_entity.account_controller.phone |
The controller's date of birth | legal_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 |
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* |
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...
Details | Parameters |
---|---|
Indicate whether the merchant is traded in any of the following:
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 name | legal_entity.public_ownership.parent_company_name |
Ticker symbol for relevant exchange(s):
| 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 requirementsThese requirements must be met before the merchant is able to receive their first Payout from their WePay Account.
Details | Parameters | Notes |
---|---|---|
All requirements associated with enabling the payments capability. | See Enable Payments | There 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 formation | entity_country_info. country_of_formation | Required for all Legal Entities. (except with legal form individual ). |
Year of entity's formation | entity_country_info. year_of_formation | Required for all Legal Entities (except with legal form individual ). |
Sanctioned countries of operation | entity_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 beneficiaries | significant_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.
Details | Parameters |
---|---|
Legal entity physical address of operation | legal_entity.address |
Controller's job title | legal_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 |
|
Define a payout frequency |
|
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:
- Resubmit Information
- Upload Verifications and Outreaches
- Verify High Volume NGOs and Charities
- Update Personal Information
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 theerrant_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 Reason | Reason |
---|---|
includes_dba | Business 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_doc | The value of the target does not match provided documentation. Advise the merchant to provide documentation that matches the requested field. |
does_not_match_government_sources | The value of the target does not match government verification sources. Advise the merchant to provide correct government information. |
invalid_url | We 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
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 thelegal_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)
{
"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 theidentity_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.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:
<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>
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);
});
}
POST /legal_entities/{id}/verifications
request like this: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 eitherunincorporated_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:
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.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.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.
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.
Detail | Parameter(s) | Notes |
---|---|---|
Significant beneficiaries' affiliates | significant_beneficiaries.affiliations | Specifies a list of affiliated Non Profit organizations to merchants. Multiple affiliations, countries of affiliations, and association types are allowed. |
Significant beneficiaries' location | significant_beneficiaries.geographies | A 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 type | significant_beneficiaries.entities | Specifies the type of entities of significant beneficiaries - multiple selections allowed. |
Significant donors' entity type | significant_donors | A significant donor is any person or entity who contributes 10% or more of the organization's total volume. |
Entity Purpose or Ideology | entity_purpose_or_ideology | Specifies the purpose or ideology of the organization. |
Entity Source and Use of Funds | source_and_use_of_funds | Specifies the information about the source and use of organization's funds. |
Indicator if Entity has significant wealth contributors | has_significant_wealth_contributors | Indicates [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 contributors | significant_wealth_contributors | Information 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:
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.