Track event refunds from request to confirmed completion

A register does not perform or prove a refund

Receiving a refund form does not move money, and typing refunded into a table does not prove that a payment provider completed a refund. This register coordinates the organiser’s review and reconciliation of the provider’s result. Eligibility and amount must be assessed against the actual sale and applicable terms by the responsible person. Use fictional examples while designing the register. Start without automatically performing live financial actions: first make it possible to see which requests are awaiting a decision, which actions were authorised and which results still require confirmation.

Keep three types of identifier

Store registration reference, payment provider, payment ID, refund ID, affected attendees, reviewed amount and currency. These identifiers matter when one payment covers several people or only part of a charge is being refunded. Do not treat an amount entered by a respondent as an authorised instruction; reconcile it against the original transaction. There is no need to copy card details into the register. Separate enquiry handling from payment permissions so an organiser can acknowledge a request without receiving unnecessary authority or access to sensitive financial information.

Model review and provider states separately

Use request states such as received, reviewing, approved and declined, with a separate payment-action column such as not started, awaiting result, completion checked or needs attention. Stripe exposes refund states and update events; creation and successful completion are different facts. If storing provider values, retain the original status and map it to an internal label instead of discarding it. Record approval, action and reconciliation times separately, even when one organiser performs all three. An unknown outcome belongs in an investigation queue rather than being counted as a completed refund.

A repeated enquiry must not create another refund

If the same attendee contacts you by both form and email, search the existing case by registration and payment references. When a refund is already awaiting a result, investigate that action rather than starting another one. After a network interruption, check provider history and refund identifiers before deciding what happened. If Make synchronises status notifications, a repeated event must not create duplicate cases or a second financial action. Keep automation that alerts an organiser separate from authority to issue refunds. A retry should reconcile an existing action wherever possible, rather than assume the first action failed.

Tell attendees only what has been confirmed

An acknowledgement can state the review process and contact route. After approval, report the verified processing state. Even after provider completion is confirmed, the register alone cannot guarantee when a particular attendee will see funds on a bank statement. Check current provider information for the relevant payment method before giving timing guidance. A confirmed failure returns to an attention queue for an authorised organiser to resolve. Do not attach payment screenshots containing personal information to a broad attendee roster or an unrestricted team chat merely to show that somebody investigated the case.

Keep the first version proportionate

For a few refunds, use the payment dashboard and an existing register, reconciling after an event or on a defined review schedule. Airtable or Make can help record requests, notify an owner and surface unresolved cases, but adding them does not guarantee financial correctness. Review software costs separately from payment and refund costs. Do not assume the same fee treatment across providers or contracts. Establish who may approve an amount before automating reminders. A small, consistently reconciled register is more useful than an elaborate workflow that labels an unverified action as finished.

Test the exception states

Exercise full and partial requests, an unknown payment, duplicate enquiries, an uncertain post-action outcome, a failure and a currency mismatch using fictional references. Test state transitions and organiser notifications without causing live refunds. Completion means the registration, approved amount, provider result and attendee communication reconcile with one another. The linked registration, Stripe test-event and duplicate-prevention guides cover neighbouring tasks. Keep their boundaries clear: receiving an enquiry, seeing a payment event and confirming the outcome of a refund are related steps, but they are not interchangeable evidence.

• Connect Make and Stripe: log test payment events without duplicate rows
• Collect workshop applications with Tally
• Prevent duplicate writes in Make with stable keys and recovery states