Skip to main content
Payment intents are the integrator-facing surface. You keep your own invoice CMS or ERP and POST a thin “intent” describing what to collect, who the buyer is, and (optionally) what to render on the hosted payment page. Caratuva runs buyer KYC, payment collection, cross-border transfer, FX, and BRL payout via PIX end to end. The endpoint returns a hostedPaymentUrl you forward to your customer. Your customer signs in with email magic-link, completes KYC if they haven’t already, and pays. You learn about every state transition through outbound webhooks.

When to use this vs. invoices

  • POST /v1/payments — your CMS owns the invoice; Caratuva is the payment + compliance + settlement engine. Skips the seller-side approval step (the API call is the approval).
  • POST /v1/invoices — Caratuva’s dashboard owns the invoice. Sellers create it, a teammate approves it if your organization requires approval, and the platform sends the magic-link. Use this if you don’t have your own invoicing system.
Buyer KYC is mandatory in both flows. There is no skip-KYC path for any payment surface.

Prerequisites

  1. KYB approved. Your organization must have completed Know-Your-Business onboarding and have a virtual account provisioned. The API returns 400 KybNotApproved otherwise.
  2. API key. A live-mode key (pk_live_...) — see API keys.
  3. Webhook subscription. You’ll want one before creating intents in production — see Webhooks.

Create a payment intent

Request body

Idempotency

Send Idempotency-Key: <uuid> on every retry of the same logical create. Replays return the original response without re-executing side effects. Two distinct keys with the same externalId collapse to the same intent (per-org externalId is itself unique).

Response

hostedPaymentUrl is the only field most integrators need from the response. Forward it to your customer over your own channel (email, SMS, in-app message). Caratuva does not automatically email the buyer when a payment intent is created — that is the integrator’s responsibility on this surface, because you already own the customer relationship.

Buyer journey on the hosted page

When the buyer clicks hostedPaymentUrl, they:
  1. Land on the buyer portal (pay.caratuva.com/r/<publicId>) and see your display block plus your seller name.
  2. Enter their email; receive a magic-link; sign in (Caratuva-managed session).
  3. Complete buyer KYC if their kycStatus is not yet approved. The KYC step is mandatory — there is no fast-forward path. A returning buyer who’s already verified in another integrator’s flow reuses their KYC and skips this step.
  4. Confirm the FX quote and complete payment.
  5. Caratuva runs the cross-border transfer and pays out BRL via PIX to the seller’s registered destination.
  6. Buyer is redirected to returnUrl if set; otherwise sees a Caratuva confirmation page.
Each transition fires an outbound webhook so your ERP can keep its order status in sync.

State machine

API-created intents skip seller-side approval (awaiting_approval / approved) and start at awaiting_buyer. From there:
Terminal failure states: failed, cancelled, expired.

Read an intent

Cancel an intent

Only valid before the BRL payout begins. After settled, cancel the order in your own system instead.

Errors

All error responses share the envelope { statusCode, error, message }.