Webhook lifecycle request
Webhook Coverage Needed For Billing Decisions
Roecny needs comprehensive transaction lifecycle webhooks so customer fees can be charged once, skipped when a transaction fails, refunded when a transaction reverses, and reconciled without repeatedly polling transaction or wallet endpoints. Polling creates unnecessary load for both systems and is not timely enough for customer-facing billing, notification, and reconciliation decisions.
This page is intentionally limited to webhook coverage. It does not contain customer personal data, account numbers, raw payloads, credentials, or unrelated API documentation.
Ticket#1082153
Reviewed through2026-06-05 10:27 UTC
Accepted/stored USD payloads2,392
Billing targetWebhook-driven, no polling dependency
Coverage Matrix
The table marks what we have observed, what is still partial or missing, and what MatchMove needs to confirm or enable so billing can be webhook-driven.
| Billing / transaction area | Coverage | Observed or current basis | Billing impact | Remaining gap | Request to MatchMove |
|---|---|---|---|---|---|
| USD SWIFT / cross-border remittance | Partial | Observed PAYOUT.TRANSACTION.CROSSBORDER.STATUS and ACCOUNTS.PAYOUT.CROSSBORDER.TRANSACTION.STATUS for USD. | Some status updates can be processed, but fee charging and fee reversal still need a polling fallback for stale transactions. | No confirmed guarantee for every document-required, final success, failed, rejected, reversed, refunded, or cancelled status change. | Enable and document the complete USD lifecycle: initiated, processing, document required, final success, failed, rejected, reversed, refunded, and cancelled. |
| SGD SWIFT / cross-border remittance | Not current scope | Roecny does not currently run SGD SWIFT transactions in production. | No immediate billing dependency for SGD SWIFT. | The same lifecycle coverage will be required before any SGD SWIFT production launch. | No immediate enablement request for SGD SWIFT. Please treat this as future launch dependency only. |
| Card purchase transactions | Partial | Observed OPENLOOP_PRE_AUTH, OPENLOOP_POST_AUTH, OPENLOOP_DECLINED_INSUFFICIENT_BALANCE, and OPENLOOP_TRANSACTION_REVERSAL. | Card purchase notifications can be triggered, but billing still refreshes wallet transactions after card webhooks to confirm wallet impact. | Final posted or settled status is not clearly separated from authorization/post-auth. Original transaction references for reversals/refunds need to be explicit. | Confirm whether OPENLOOP_POST_AUTH is final for billing. Provide final posted/settled, refund, reversal, and original-transaction reference fields. |
| Card ATM withdrawal and card FX / cross-border fees | Missing | No distinct ATM withdrawal or card FX fee lifecycle event has been confirmed in accepted production payloads. | ATM and card FX fees cannot be safely charged from webhook data alone. Polling or later wallet transaction sync is still needed. | ATM withdrawal, FX/cross-border fee, final settlement, and refund/reversal events are not confirmed. | Provide event names and payload fields for ATM withdrawals, card FX/cross-border fees, final settlement, and fee reversals/refunds. |
| Virtual-account / wallet pay-in | Partial | Observed USD and SGD bank-transfer credit success events. A small number of failed credit attempts have also appeared. | Pay-in notifications and some pay-in fee decisions can be triggered, but reversals/recalls cannot be handled reliably from webhooks alone. | Credit recall, reversal, refund, failed final state, and final settlement indicator are not confirmed. | Confirm whether pay-in recall, reversal, refund, failure, and final settlement webhooks exist and enable them for both USD and SGD. |
| SGD FAST / domestic payout | Partial | Observed bank-transfer debit success and debit-reversal success events in received attempts. | A success/reversal signal exists, but the full payout lifecycle is not confirmed enough for webhook-only fee processing. | Initiated, processing, failed, rejected, cancelled, and refunded status changes are not confirmed. | Provide the complete FAST payout lifecycle events and state fields: initiated, processing, final success, failed, rejected, reversed, refunded, and cancelled. |
| Mastercard Rail payout | Missing | No distinct Mastercard Rail payout lifecycle event family has been confirmed in production payloads. | Mastercard Rail payout fees cannot be safely charged or reversed from webhook data alone. | Initiated, processing, final success, failed, rejected, reversed, refunded, and cancelled events are missing or not identified. | Provide and enable the full Mastercard Rail payout lifecycle with transaction ID, amount, currency, status, sub-status, and failure/reversal reason. |
| Wallet debit / internal transfer / P2P | Partial | Wallet debit records can be seen through wallet transaction data. No dedicated P2P lifecycle webhook is confirmed. | Internal transfer status still depends on wallet transaction retrieval when a direct lifecycle event is not available. | Dedicated initiated, success, failed, reversal, refund, and original-transaction reference events are not confirmed. | Confirm whether wallet debit and internal transfer lifecycle webhooks are supported and provide exact event names and payload fields. |
| Virtual-account status | Partial | Observed USD individual and business virtual-account status events with pending, pending activation, active, and rejected states. | Account activation can be reflected for some USD cases, but blocking/closure changes may still require manual checks or polling. | Suspended, blocked, closed, and corresponding SGD status events are not confirmed. | Confirm and enable virtual-account suspended, blocked, closed, rejected, pending, pending activation, and active status webhooks. |
| Webhook delivery controls | Partial | Some requests are accepted; some are accepted through source-IP allowlist. Retry and signature behavior is not uniform. | Billing and reconciliation depend on reliable delivery, idempotency, retry, and verifiable authenticity. | Retry schedule, retry window, delivery failure handling, and HMAC signature coverage are not confirmed for every event family. | Confirm retry policy, retry duration, signature scheme, signature requirement, idempotency key, and delivery failure behavior for all webhook families. |
Fields Required In Each Lifecycle Event
- event name, event timestamp, and delivery idempotency key
- transaction ID and original transaction ID for refunds, reversals, recalls, and cancellations
- user ID, wallet ID, virtual-account ID, card ID, or payout recipient ID where applicable
- amount, currency, fee amount, fee currency, and final debited or credited amount
- status, sub-status, failure reason, reversal reason, refund reason, and document-required reason
- finality indicator so we know whether a fee can be charged, skipped, or reversed