Create a new payee. The payerId is inferred from the authenticated caller.
If externalId is supplied and already used by another resource of this type for the owning Account, the request returns 409 ResourceConflict; create is not an upsert. Use filter[externalId][eq] on the list endpoint to retrieve the existing resource.
profile.email is also not an upsert key, and a duplicate does not always conflict. Which of the two outcomes below you get turns on internal record keying, NOT on anything this API exposes — so handle both rather than trying to predict which:
-
409 ResourceConflictwithdetailCodepayments.PayeeEmailConflict. Retrieve the
blocking payee withfilter[email][eq]on the list endpoint, thenPATCHit with
whatever you meant to change. An email held only by aDeactivatedpayee does not
conflict at all; that create proceeds. -
201with the PRE-EXISTING payee, reactivated if it wasDeactivated.
Nothing you submitted is applied, andevents.createdAtis the original creation time —
so a201does not by itself mean a payee was created.
When that pre-existing payee's context differs from the requested one, the request returns 409 ResourceConflict instead of the 201. PATCH cannot change context; use POST /v3/payments/payees/{payeeId}/change-context.
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||