Skip to main content
This event fires as soon as the payment gateway (Asaas, Stripe, etc.) confirms a paywall payment. It’s the canonical moment to sync access in external systems (legacy member area, course platform, ERP), since internally Cativa also uses this same event to grant the user a badge/group/course.
The internal event name (used when subscribing webhooks in the Console) is paywall_payment_completed.

Subscribe to this event

Point a listener at your URL with EventName: "paywall_payment_completed". Auth, secret and verification in Subscribing and verifying webhooks.

When it fires

  • Payment gateway (Asaas, Stripe) sends the confirmation callback to Cativa
  • A PIX payment clears
  • A boleto charge clears
  • A credit-card charge is captured successfully
  • A manual payment is marked as confirmed in the admin

When it does NOT fire

  • Payment created but still pending (PIX generated and not paid, boleto not yet due, etc.)
  • Payment failed or cancelled by the gateway
  • Payment refunded after it had been confirmed
  • Payment without a resolved UserId (e.g. PIX where the payer hasn’t been associated with a tenant user yet) — delivery is skipped
  • Paywall or payment not found while enriching the payload (delivery is skipped)

Payload

The payload is serialized in PascalCase and delivered in the body of the POST with Content-Type: application/json. The payload has three nested objects — User, Paywall and Payment:

Payload fields

Root

User

Paywall

Paywall.ActionType follows the enum:

Payment

The Portuguese-named fields (ValorPago, ValorOriginal, Desconto, TipoPagamento, IdTransacao) are inherited from v1 of the platform and kept for compatibility with existing Make/Zapier integrations. They will not be renamed.

Request headers

The full explanation of how to verify X-Cativa-Signature, handle retries and ensure idempotency (with examples in Node, Python, Go and C#) lives in Subscribing and verifying webhooks.

Use cases

  • Grant access in an external platform — if you still host part of the content outside Cativa (legacy member area, Hotmart, Memberkit), use Payment.PaymentId + User.Id to provision access there as soon as the payment is confirmed.
  • Financial reconciliation — record Payment.IdTransacao + Payment.Gateway + Payment.ValorPago in your ERP/accounting to close the books per gateway.
  • Send a transactional email — fire a receipt, invoice or “purchase confirmed” welcome message using User.Email, Paywall.Name, Payment.ValorPago and Payment.Installments.
This event fires once per confirmed payment — it does not fire on automatic subscription renewal (recurring billing is not yet in production). Don’t treat this event as a renewal trigger.

Reacting to the event

After verifying the signature, grant access in your external platform. Payment.PaymentId is unique per confirmed payment, so it doubles as the idempotency key. Paywall.ActionType tells you what the purchase grants (see the enum table above):

user_received_badge

Fired when the paywall grants a badge — useful to pair the granted permission with the payment.

user_joined_group

Fired when the paywall adds the buyer to a group (ActionType 3 or 5).

Subscribing to webhooks

How to register listeners, verify HMAC and handle retries.

Webhooks (overview)

Why webhooks, delivery guarantees and payload format.