Payins

Every entity in payins reports its lifecycle through webhooks: 7 template events, 7 intent events, 5 payin events, and 3 settlement batch events — 22 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.

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.
`payin_intent_awaiting_payment`	A payin for the intent was authorized; the payment is in flight.
`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`.
`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. `state_reason` explains.
`payin_intent_expired`	The window closed with nobody paying. The `external_id` is freed for a new intent.

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`).
`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.
`payin_failed`	A system or provider failure — `lock_timeout` or `unknown`.

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

A payin's brief awaiting_payment state has no event of its own — the intent's payin_intent_awaiting_payment covers that moment.
Template state transitions caused by an update travel inside payin_template_updated, not as separate state events.
Settlement batch retryable (transient, retried automatically) and failed (terminal, resolved manually by Mono) are readable via the API but never notified.

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.