Data Handling & Compliance
What identity data onboarding collects for Know-Your-Business review, how sensitive fields are returned masked, and how calls are secured.
Onboarding a business means handling regulated identity data. This page is for a security or compliance reviewer assessing the integration: what data onboarding collects, how sensitive values are returned, and how calls are secured. It states only what the boarding contract confirms; anything set by policy is called out for your security and compliance teams to confirm.
What onboarding collects
Onboarding collects the identity data needed to satisfy Know-Your-Business (KYB) and Know-Your-Customer (KYC) review before a business can process payments:
- Business identity: legal name, business type, incorporation details, tax IDs (EIN, SSN, ITIN, or foreign), industry, and contact details.
- The people behind the business: owners and signatories, each backed by a shared Individual, with name, date of birth, nationality, tax ID (SSN or ITIN), and one or more government IDs.
- Operating and funding data: business addresses, locations and their processing profiles, and bank accounts.
You send this data so underwriting can verify the business and the people who own and control it. See Businesses for the full model and Business validation & KYB rules for the rules it must satisfy.
How sensitive data is returned
You write sensitive values in full, but onboarding returns them masked. A GET never echoes a full account number, tax ID, or government ID back to you:
| You send | It is returned as |
|---|---|
Bank accountNumber | accountNumberLast4 (last four digits only) |
Tax ID value | lastFour (last four digits only) |
Government ID number | numberLastFour (last four digits only) |
A routing number is not returned at all. Because a GET returns masked, read-only fields, don't send a record back unmodified; send only the fields you are changing. See API Error Handling for the read-only-field behavior.
PENDING-PUBLISHThe exact masked-field set is drawn from observed responses while the boarding spec is absent from the API Reference. Confirm the full set of masked and read-only fields against the published spec before publish. (Owner: eng.)
Transport and authentication
- HTTPS only. Every onboarding call is made over HTTPS. Plain HTTP is not accepted.
- API key per request. Every endpoint authenticates with an API key in the
x-api-keyheader (x-api-key: <your-key>). Contact PCE Integration Support to obtain and rotate credentials. Keep the key server-side; never embed it in a browser or mobile client.
See Getting Started for access and base URLs.
For your security and compliance review
The boarding contract does not state the following. Route each to your Priority Commerce contact so your security and compliance teams can confirm it directly:
PENDING-PUBLISHThe following are not defined by the boarding contract and must not be asserted in docs until confirmed by security and compliance: data retention periods, encryption-at-rest and encryption-in-transit specifics, PCI DSS and SOC posture and attestations, and data-residency or sub-processor commitments. Gather the confirmed answers and add a factual summary here. (Owner: security/compliance.)
See also
- Getting Started: access, authentication, and base URLs
- Businesses: the identity data model and how the resources relate
- Business validation & KYB rules: the KYB rules a business must satisfy
- API Error Handling: masked and read-only field behavior
Updated about 10 hours ago