Verification requirements
Verification requirements define what information must be collected for a connected account before it can operate.
They are the source of truth for onboarding and should drive both your UI and backend logic.
Requirements model
Each account exposes a set of requirements through the API.
{
"requirements": {
"currently_due": [
"business_profile.name",
"company.tax_id"
],
"eventually_due": [
"company.verification.document"
],
"past_due": [],
"pending_verification": []
}
}
Requirement states
Requirements are grouped into the following categories:
currently_due
Fields that must be collected immediately.
If these are not satisfied, the account cannot become operational.
eventually_due
Fields that may be required later.
These do not block the account immediately but must be collected over time.
past_due
Fields that were required but were not provided in time.
Accounts with past due requirements may have restricted capabilities.
pending_verification
Fields that have been submitted and are currently under review.
No further action is required until verification completes.
How to use requirements
Your platform should treat requirements as a dynamic contract.
Retrieve the latest account state from the API.
Read the requirements fields to determine what is missing.
Collect the required information from the user.
Send the collected data to the API.
Continue until no blocking requirements remain.
Example flow
A newly created account may return:
{
"requirements": {
"currently_due": [
"business_profile.name",
"representative.first_name"
]
}
}
After submitting data:
{
"requirements": {
"currently_due": [],
"pending_verification": [
"representative.identity_document"
]
}
}
After successful verification:
{
"requirements": {
"currently_due": [],
"pending_verification": []
}
}
Relationship to other resources
Requirements span multiple resources:
- Account fields (for example:
business_profile,company) - Persons (for example:
representative,owners) - Documents (uploaded via Files API)
A single requirement may require updates across multiple endpoints.
Capabilities and requirements
Requirements are directly linked to capabilities.
Requesting a capability introduces additional requirements.
Example:
{
"capabilities": {
"payments": "inactive"
},
"requirements": {
"currently_due": [
"company.tax_id"
]
}
}
A capability becomes active only after all required fields are satisfied and verified.
Dynamic behavior
Requirements are not static.
They may change when:
- New capabilities are requested
- Verification fails
- Regulations change
- Account data is updated
Do not hardcode onboarding flows. Always derive required fields from the API response.
Requirements and tasks
Requirements indicate what information or action is needed.
For certain requirement types, Paypercut also provides tasks that include structured instructions for how to fulfill them.
For example:
- A requirement may indicate that an agreement must be accepted
- A task provides the agreement bundle, document links, and required confirmations
Use requirements to determine what is needed, and tasks to determine how to fulfill it.
See:
Best practices
- Always fetch the latest account before rendering onboarding steps
- Use requirements to drive your UI dynamically
- Handle requirement changes via webhooks
- Treat requirements as the single source of truth for onboarding state
Summary
Requirements define:
- What data must be collected
- When it must be collected
- Whether verification is complete
Your integration should be entirely driven by the requirements model.
