Customer lifecycle: requirements, RFIs and closing

SET API and SET Merchant API · Live since 2026-11-09

Knowing what a customer still owes

• customer.requirements_due: sent when the list of requirements the provider says are due changes, including when it empties. data.requirementsDue holds requirement names only (for example proof_of_address), sorted, never values. Send what is missing with POST /v1/customers/{id}/kyb.
• rfi.created: sent once for each open request for information. It carries the RFI's id, state, category, deadline, and per requested item its id, status and the kinds of response accepted. It never carries the question's text: read it with GET /v1/customers/{id}/rfis and answer with POST /v1/rfis/{id}/responses.

Closing a customer

POST /v1/customers/{id}/close offboards a customer in one call, in this order:

1. Each active virtual account is deactivated (virtual_account.deactivated).
2. Its Cash-Out Addresses are retired (cash_out_address.retired).
3. Its recipients are disabled (recipient.disabled).
4. The customer is marked closed (customer.closed); GET /v1/customers/{id} shows closedAt.

If a deactivation is refused, the customer stays open (502) and the call can be repeated. A repeat after closing changes nothing.

A closed customer opens nothing new: every create that names it, and /reactivate on its virtual accounts, answers 409 customer_closed.

What closing does not do

• A Cash-Out Address cannot be deactivated at the provider, so it is retired in SET only. A payment still sent to it is paid to the bank and recorded.
• Custodial wallets are not touched. Their balance stays the customer's.
• Payments and payouts under way run their course.
• Data held by the provider stays under the provider's own retention.

Test it

POST /v1/sandbox/scenarios with kyb_rejected or rfi_raised raises these outcomes in staging (Sandbox scenarios).