Per-user, per-type lock

BlendFi limits each end customer to one open conversion per type (pix_onramp or pix_offramp) at a time. Trying to create a second onramp conversion for the same end customer while the first is open returns an error.

The rule

For any (user_id, transaction_type), at most one conversion may be in the open states: awaiting_deposit (and, on offramp, also partially_funded and standby).

The rule is permissive across directions: the same end customer can have one open onramp and one open offramp at the same time, just not two of the same type.

Why this rule exists

Each onramp conversion has a dedicated Pix QR with a unique Pix transaction id (pix_tx_id) registered at the provider. Allowing two open onramp conversions for the same end customer would create concurrent QRs that could be paid out of order or both. The rule eliminates the ambiguity at the source.

When the lock releases

The lock is released as soon as the conversion enters a terminal state:

• completed, failed, expired, canceled.

The error you receive

Calling POST /v1/quotes/:id/accept for a user_id that already has an open onramp conversion returns an error with a stable code (the full spec lands in the API reference). The error's request_id lets support trace the call.

Suggested handling

When you receive the lock error:

1. Check whether the open conversion belongs to this same flow. If it is the same end customer trying to re-confirm an operation that is still valid, take the UX back to the existing conversion's Pix QR.
2. If the open conversion is old and the end customer gave up, cancel the prior one (if still in awaiting_deposit) or wait for the 15-minute window to expire (expired). The new accept call passes after.

Next steps

• Cancellation: how to release the lock before payment arrives.