Check the requirements
Endpoint:GET /crypto/onramp/{serviceProvider}/requirements
Returns everything standing between this customer and an accepted order with that provider: agreements to sign, contacts to verify, and KYC still outstanding.
What comes back, and what to do
Four things, independent of each other. A customer can be through KYC and still be blocked on an unaccepted agreement. Work through them in the order below, then re-check.Legal agreements
Terms this provider wants the customer to see before it will take the order.url in your own UI and gate your own flow on the customer accepting. An empty array means there is nothing to show.
Contact verification
Whether the provider wants the customer’s email or phone confirmed by a one-time code. Two keys work together:verificationRequirements is what the provider asks for, customerStatus is how far this customer has got.
satisfied is about verification, not about whether the value is on the customer. MISSING means never verified — the customer may well have an email on record. A customer with no value at all has to have one set on the customer before there is anything to verify.
Verify only the channels that are required and not yet satisfied:
POST /accounts/customers/{customerId}/verifications, then POST /accounts/customers/{customerId}/verifications/{verificationId}/confirm
See Email and phone verification.
STALE and VOIP both describe a customer who has verified before. A bare “verify your phone” reads as a bug to them unless you explain it.
On VOIP. A phone number has a line type — mobile, landline, or a virtual number from an internet calling service. A provider that sets requireLineType: "MOBILE" will not accept the last two, because a number anyone can mint for free is weak evidence of who the customer is. The reason is named after the common case rather than the rule: it means “not the line type this provider requires”, so it would also cover a landline.
It only fires when the line type is actually known. An unscreened number is left alone instead of being refused; otherwise a requireLineType policy would fail every customer. That makes VOIP rare in practice, and a provider that cares usually enforces its own rule on its side instead, so a number can still be refused later without this ever appearing. Expect MISSING and STALE.
KYC requirements
One entry per KYC step this provider needs, each reported independently.
Collect everything in
missingFields across all requirements in one pass, then send it as serviceProviderDetails on:
PATCH /accounts/customers/{customerId}/kyc/initiate
PATCH, not POST. The customer already has a KYC session by this point — POST starts one. This adds the provider’s own extra details to the session that exists. See Unified KYC for the modes and the payload.
Reading status
Two of these are easy to get wrong.
PENDING is not failure. Treating it as REQUIRED sends the customer back through a form they have already filled in, and some providers review asynchronously, so it can last minutes.
BLOCKED is not retryable. Re-submitting will not clear it. It is provider-specific, so the other providers in the quote are usually still open.
Re-check before you create the order
Call the endpoint again with the same five order parameters. Submitting is not the same as satisfied: a provider may still be reviewing, andPENDING will not accept an order.