Payins

Every entity in payins reports its lifecycle through webhooks: 7 template events, 7 intent events, 6 payin events, and 3 settlement batch events (23 in all). Each payload carries the full resource, in the same shape the API returns it. This page places every event on the timeline; the exact payloads live in the Payin Webhooks API reference. For signature verification, retries, and money-field conventions shared by all Mono webhooks, see Webhook conventions.

The happy path, in order

For a collection through an intent, a single payment produces this sequence:

Collections without intents skip the four intent events; the template events fire once per template, not per payment.

With PSE

A PSE payment always goes through an intent, and Mono creates its payin before the payer pays. payin_intent_created and payin_created are produced together, when the intent is created:

The diagram assumes the on_approval trigger. With on_funds_delivery, payin_subaccount_credited waits until the money arrives on the ACH cycle. payin_intent_attempt_failed never arrives: a failed PSE payment ends with payin_failed and payin_intent_failed.

Template events

Event	Arrives when
`payin_template_created`	The template is accepted and persisted. Its payment tokens are still being set up (`payment_tokens` is null). It cannot receive payments yet.
`payin_template_ready`	Token setup finished: the template can receive payments, and `payment_tokens` carries one entry per method that issues a token (for Bre-B, the key and QR).
`payin_template_updated`	Every successful update. Carries `previous_values` with the fields that changed, including a state transition caused by moving the totals, which does not fire the separate state events.
`payin_template_minimum_paid`	Cumulative `paid_amount` first reaches `total_minimum_amount`. The template keeps accepting payments.
`payin_template_paid`	`total_maximum_amount` is reached, or a `single_use` template received its payment. No further payins are accepted.
`payin_template_discarded`	The template was deleted, expired, or swept for inactivity; its tokens were torn down. `prune_reason` says which.
`payin_template_failed`	Token setup exhausted its retries. `state_reason` explains (e.g. `key_already_registered`).

Intent events

Event	Arrives when
`payin_intent_created`	The intent is accepted and persisted. Its token is still being prepared. The payer cannot pay yet.
`payin_intent_ready_to_pay`	The intent becomes payable: `payment_tokens` and `expires_at` are set. Also re-sent when the intent re-arms after a failed attempt. For PSE, `payment_tokens.pse_url` is the link to send the payer to.
`payin_intent_awaiting_payment`	A payin for the intent was authorized; the payment is in flight. For PSE, it follows `ready_to_pay` right away, once the payment link is generated.
`payin_intent_attempt_failed`	A payment attempt failed after authorization but the intent survives: it is back in `ready_to_pay` for a retry. The attempt itself arrives as `payin_rejected` or `payin_failed`. Never sent for PSE, which allows one attempt per intent.
`payin_intent_successful`	The intent was spent by its successful payment. Final: tokens torn down.
`payin_intent_failed`	The intent fails for good: token registration failed, or a payment failed with no re-arm, as every failed PSE payment does. `state_reason` explains.
`payin_intent_expired`	The window closed with nobody paying. The `external_id` is freed for a new intent. For PSE, only a hosted checkout intent whose payer never sent the form.

Payin events

Event	Arrives when
`payin_created`	A payment is first persisted, before provider confirmation. Carries who paid (`instrument.payer`) and on which key (`recipient_data`). For PSE, it arrives with the intent, before the payer pays: a payment attempt, not money received.
`payin_awaiting_payment`	PSE only. The payment link was generated, and Mono waits for PSE to report the outcome. The first event that carries `transaction_data.cus`. Not confirmed yet: that is `payin_approved_in_provider`.
`payin_approved_in_provider`	The provider confirmed the payment. Money exists on the provider side; the subaccount is not credited yet.
`payin_subaccount_credited`	The subaccount was credited for `subaccount_amount`. For most integrations, the "payment complete" signal.
`payin_rejected`	A business, configuration, or payer condition stopped the payment. `state_reason` explains (e.g. `amount_exceeds_maximum`, `payer_not_allowed`). The payer's funds, if any, are returned. Never sent for PSE.
`payin_failed`	The payment did not complete after the payin was accepted, or Mono could not process it. `state_reason` explains (e.g. `breb_timeout`, `lock_timeout`). For PSE, every payment that does not go through, with the reasons in Payin errors.

Settlement batch events

Event	Arrives when
`payin_settlement_batch_created`	Pending payins were grouped into a batch. `payins` lists what each contributes; the money has not moved yet.
`payin_settlement_batch_processing`	The delivery provider accepted the batch transfer.
`payin_settlement_batch_completed`	The funds reached your funding account.

What is not notified

With Bre-B, a payin's brief awaiting_payment state has no event of its own; the intent's payin_intent_awaiting_payment covers that moment. A PSE payin does emit payin_awaiting_payment.
A PSE delivery that completes without a settlement batch (funds_destination: method_receiving_account) has no event of its own. Read the payin's funds_delivery_status, or, with on_funds_delivery, wait for payin_subaccount_credited.
Template state transitions caused by an update travel inside payin_template_updated, not as separate state events.
Settlement batch retryable and failed are readable via the API but never notified: Mono is handling the delivery, and you do not need to act.

Next steps

Webhook conventions: signatures, retries, and delivery rules.
Payin Webhooks API reference: the exact payload of each event.
Flows: the events in the context of each use case.

Payins

On this page