A delegate emails three weeks before the conference to say they can no longer attend. They paid online. They want their money back. The organiser has no written refund policy. The payment was processed through Stripe. The organiser is not sure whether the gateway fee comes back with the refund, whether the attendee record needs to be updated manually, or what the GDPR position is on retaining data for someone who has cancelled.
Refund handling is not a feature event management platforms advertise. It sits in the gap between the payment gateway, the attendee database, and the organiser’s own policy decisions. Get it wrong and the organiser faces a payment dispute, a fragmented attendee record, or a compliance question they are not prepared for.
This article covers what a clear event refund policy looks like, how the refund process works when payments run through Stripe or PayPal, the specific steps involved when using Evenio, and the mistakes that create unnecessary cost and risk for Malta event organisers.
Why Refund Handling Creates Problems When There Is No Process
Most event refund problems are not payment problems. The payment gateway processes refunds reliably. The problems arise in the steps around it: what the organiser communicates to the delegate, whether the attendee record is updated after the refund is processed, and whether the organiser has a documented policy to refer to when the request arrives.
The specific failure points Malta organisers encounter:
- No written refund policy means each request is handled case by case, creating inconsistency and the risk of disputes when one delegate receives different treatment from another.
- The refund is processed in the payment gateway but the attendee record in the event platform is not updated, leaving a cancelled delegate on the check-in list and in the attendance count.
- The organiser is unaware that gateway fees may not be returned on a refund, meaning the refunded amount does not match the original charge, and neither the organiser nor the delegate was prepared for this.
- The delegate receives no formal written confirmation of the cancellation and refund, creating a support queue if the refund takes several business days to appear.
- Data retention after a cancellation is not considered, leaving the organiser uncertain about whether retaining the cancelled delegate’s registration data complies with GDPR.
Each of these is a planning failure rather than a technical one. A documented process prevents all of them.
What a Clear Event Refund Policy Looks Like
A professional event refund policy is not a legal document. It is a set of decisions made in advance and communicated clearly, so that both the organiser and the delegate know what to expect when a cancellation occurs. The elements that should be in place before registration opens:
- A defined refund window: the period within which a delegate can request a full refund. Common structures are full refund up to a specified number of days before the event, partial refund within a shorter window, and no refund inside a final period before the event date.
- A clear position on transfers: whether a delegate can transfer their registration to a colleague or replacement attendee, and whether this is permitted within the no-refund period as an alternative to cancellation.
- A documented process for submitting a refund request: an email address, a contact form, or a named contact. Not a general enquiry inbox.
- A stated timeline for processing: how long the refund takes to appear, and acknowledgement that gateway processing times are outside the organiser’s control.
- A statement on gateway fees: whether the refund covers the full original charge or the original charge minus any non-recoverable gateway fees.
- A GDPR-compliant data retention position: confirmation that the cancelled delegate’s registration data is retained for financial record purposes for the statutory period, and that it will not be used for future marketing without renewed consent.
- Publication of the policy: visible at the point of registration, not buried in a terms page linked from the footer.
Decision Framework: Refund Process Models for Malta Events
Three approaches to handling event refunds, and how they compare across the criteria that matter for professional event management:
| Criteria | Manual / No formal policy | Platform-integrated refund | Evenio two-step process |
|---|---|---|---|
| Where refund is processed | Bank transfer manually reversed or cash returned. No gateway record. | Within the ticketing platform. Single action. | In Stripe or PayPal directly by the organiser. Separate to Evenio. |
| Attendee record update | Manual removal from list. Risk of remaining on check-in system. | Platform updates record automatically on refund. | Organiser updates attendee status in Evenio backend after completing the gateway refund. Two deliberate steps. |
| Financial trail | No documented refund trail. Risk of dispute with no evidence. | Platform holds refund record. Gateway record also exists. | Full refund record in Stripe or PayPal. Evenio records updated status only. Complete audit trail across both. |
| Gateway fee recovery | Not applicable. No gateway involved. | Varies by platform. Some recover gateway fees on refund, some do not. | Governed entirely by Stripe or PayPal policy. Not an Evenio function. Gateway fees may not be returned on refund depending on gateway and territory. |
| GDPR data handling on cancellation | Manual deletion required. No audit trail of deletion. | Depends on platform policy. Data may be retained for financial records. | Attendee data retained in Evenio for financial record purposes per GDPR legitimate interest. Organiser controls export and deletion timeline. |
| Risk of processing twice | High. No system prevents double payment or double refund. | Low. Platform typically prevents duplicate refunds. | Gateway prevents duplicate refunds. Evenio record update is separate and manual, but the financial action is gateway-controlled. |
The Evenio two-step process is deliberate by design. Keeping the financial action in the gateway and the record update in the platform maintains a clear separation: the gateway handles money, Evenio handles attendee data. Neither overwrites the other. The organiser controls both steps and has a complete audit trail across both systems.
Common Mistakes Malta Event Organisers Make with Refunds
Having no written refund policy at point of registration. When there is no policy, every refund request is a negotiation. The outcome depends on who asks and how they ask, not on a consistent standard.
What it looks like: a delegate requests a refund two weeks before the event. Another delegate makes the same request and is refused because the organiser has committed more budget since the first refund was approved. The second delegate escalates. Why it happens: refund policy is treated as something to deal with when it comes up. What it costs: time, relationship damage, and the risk of a payment dispute if the delegate escalates through their card provider.
Processing the gateway refund without updating the attendee record. Refunding in Stripe or PayPal is one step. Updating the attendee status in Evenio is a separate, required step.
What it looks like: a cancelled delegate remains on the check-in list, is counted in the expected attendance figure, and appears in the post-event report as a no-show rather than a cancelled registration. Why it happens: the organiser treats the payment refund as the complete action. What it costs: inaccurate attendance data, a no-show count that includes cancellations, and a post-event report that does not reflect actual demand.
Promising a full refund without accounting for gateway fees. Payment gateway fees, once deducted, may not be returned when a refund is processed. This depends on the gateway (Stripe or PayPal) and the territory. Telling a delegate they will receive a full refund before checking the gateway’s policy creates a shortfall.
What it looks like: an organiser confirms a full refund. The gateway processes the refund minus the original transaction fee. The delegate receives less than expected and contacts the organiser. Why it happens: the organiser assumed the refund process was symmetrical: pay in full, receive back in full. What it costs: a conversation with a delegate who expected a different amount, and a budget shortfall if the organiser makes up the difference.
Not confirming the refund in writing to the delegate. A refund initiated in the gateway is not immediately visible to the delegate. Card processing timelines vary. Without written confirmation, the delegate assumes nothing is happening.
What it looks like: a delegate requests a refund on a Monday. The organiser processes it the same day. The delegate emails again on Wednesday asking for an update because nothing has appeared on their statement. Why it happens: the organiser assumed the gateway notification was sufficient. What it costs: unnecessary support overhead and a delegate who questions whether the refund was processed at all.
Using refund handling as an opportunity to renegotiate the delegate’s attendance. When a delegate requests a refund, the instinct to offer a discount or alternative is understandable. It is also the moment when the clearest response is to honour the documented policy without conditions.
What it looks like: a delegate requests a refund within the stated window. The organiser offers a transfer or a partial credit instead, without first confirming whether the delegate wants an alternative. The delegate declines, escalates, and the dispute takes longer to resolve than a straightforward refund would have. Why it happens: the organiser wants to retain the registration. What it costs: a longer resolution, a worse delegate experience, and the same outcome.
Retaining cancelled delegate data indefinitely without a policy. Cancelled delegates are still data subjects under GDPR. Retaining their registration data without a documented basis and a defined retention period is a compliance risk.
What it looks like: three years after the event, a former delegate submits a Subject Access Request and finds their data still in the organiser’s event system with no record of why it was retained. Why it happens: data deletion was never part of the post-event process. What it costs: a compliance exposure and an administrative exercise that could have been avoided with a defined retention period documented at the point of registration.
How Refund Handling Works in Evenio
Refund handling in Evenio involves two separate steps, each in a different system. Understanding the distinction between the two prevents the most common errors.
Step 1: Process the refund in Stripe or PayPal. The organiser logs into their Stripe account or PayPal account directly and initiates the refund from within the gateway. Evenio does not process, handle, or trigger refunds. The financial action is entirely within the gateway. The gateway processes the refund according to its own policies and timelines, which are outside Evenio’s control.
Step 2: Update the attendee status in Evenio. After the gateway refund is confirmed, the organiser updates the delegate’s status in the Evenio backend to reflect the cancellation. This is a manual step. It removes the delegate from the active attendee count, ensures they do not appear on the check-in list, and correctly categorises them in the post-event report as a cancellation rather than a no-show.
These two steps are intentionally separate. The gateway controls the money. Evenio controls the attendee record. Neither system overwrites the other. The organiser has a complete trail: the refund record in the gateway and the updated status in Evenio.
A few specific points about how this works in practice:
- Evenio records the full amount paid at the moment of registration. It does not show gateway fees, net-of-fee amounts, or settlement data. The financial details of the refund, including whether gateway fees are returned, are visible only in the gateway.
- The invoice generated at the moment of registration is not automatically reversed within Evenio when a refund is processed. If a credit note or revised invoice is required for the delegate’s records, this is produced separately on instruction.
- There is no automated notification sent from Evenio to the delegate when a refund is processed. Communication about the refund is managed by the organiser directly.
- Partial refunds follow the same process: the partial amount is refunded within the gateway, and the attendee record is updated in Evenio to reflect the revised status.
Refunds and GDPR: What Malta Organisers Need to Know
A cancelled delegate’s registration data does not disappear from GDPR scope when the ticket is refunded. The data was collected for a specific purpose (event registration), the purpose has ended (the delegate cancelled), but the data may still need to be retained for financial record purposes.
The GDPR-compliant position for Malta event organisers:
- Retain registration and payment data for the statutory period required for financial records under Maltese law. This is separate from marketing consent. Retaining a financial record is not the same as retaining marketing permission.
- Do not use the cancelled delegate’s contact details for future event marketing without renewed consent. Cancellation does not constitute withdrawal of any prior marketing consent, but it also does not create a basis for continued marketing if consent was not separately obtained.
- Document the data retention position in the registration terms and in the refund policy. If a delegate asks why their data is still being held after cancellation, the answer should be readily available.
- Define the deletion timeline. At the end of the statutory retention period for financial records, the data should be deleted or anonymised. This should be a scheduled process, not something that happens only if a delegate requests it.
For Malta organisers running events in regulated sectors, particularly financial services, healthcare, and iGaming, the data retention question on cancellation may require additional consideration specific to the sector’s regulatory framework.
Investment and Pricing Logic
Refund handling does not add to the Evenio platform fee. The per-attendee charge applies to confirmed registrations at the time of the event. A delegate who cancels and is refunded before the event is removed from the active attendee count in Evenio; the pricing impact of the cancellation is a commercial matter between the organiser and the Evenio account team, not an automatic adjustment.
Gateway fees on refunds are governed by Stripe and PayPal policy respectively and are not an Evenio variable. Organisers should verify the current gateway policy on fee recovery before committing to a full refund guarantee in their event terms.
Next Step
If you are setting up event registration for a Malta event and want to understand how the payment, refund, and attendee data flow works end to end, the Evenio demo covers the full process from registration to post-event reporting in one session.
Pricing is not discussed at this stage. The demo is a platform walkthrough.
FAQs
What should an event refund policy include for Malta organisers?
A clear event refund policy should define: the window within which a full refund will be provided (for example, up to 21 days before the event), whether partial refunds apply within a shorter window, whether registration transfers to a colleague are permitted as an alternative to cancellation, the process for submitting a request, the expected timeline for the refund to appear, a statement on whether gateway fees are recovered, and the GDPR data retention position for cancelled delegates. The policy should be visible at the point of registration, not only in the general terms and conditions. Establishing the policy before registration opens eliminates case-by-case negotiation and gives delegates a clear basis for their decision.
How does Evenio handle refunds?
Evenio does not process refunds. The refund process involves two separate steps managed by the organiser. First, the organiser logs into their Stripe or PayPal account directly and initiates the refund within the gateway. Second, after the gateway refund is confirmed, the organiser updates the delegate’s attendee status in the Evenio backend to reflect the cancellation. These are two deliberate, separate actions: the gateway handles the financial transaction, Evenio handles the attendee record. The organiser has a complete record across both: the refund confirmation in the gateway and the updated status in Evenio. Evenio does not automatically notify the delegate when a refund is processed.
Are gateway fees returned when an event ticket is refunded?
This depends on the payment gateway and the territory, not on Evenio. Stripe and PayPal each have their own policies on fee recovery for refunded transactions. In some cases the original transaction fee is returned with the refund; in others it is not. Evenio does not control or influence this: the gateway processes the refund according to its own rules, and the financial outcome is visible in the gateway account, not in Evenio. Malta organisers should verify the current policy with their gateway before publishing a refund policy that commits to returning the full original charge, to avoid a shortfall if the gateway fee is non-recoverable.
What are the GDPR obligations when an attendee cancels?
When an attendee cancels, their registration and payment data becomes subject to a different legal basis: legitimate interest for financial record retention rather than the original registration purpose. The data should be retained for the statutory period required for financial records under Maltese law, then deleted or anonymised. The cancelled delegate’s contact details should not be used for future marketing unless consent was separately obtained and has not been withdrawn. The data retention position should be documented in the registration terms and communicated clearly in the refund confirmation. For events in regulated sectors, additional sector-specific data retention requirements may apply.
What is the difference between a cancellation and a transfer?
A cancellation means the original delegate withdraws their registration and receives a refund (subject to the refund policy). A transfer means the registration is reassigned to a different delegate, typically a colleague or replacement, without a refund being processed. Transfers are a practical alternative to cancellations when the delegate cannot attend but the organiser does not want to refund the place. Whether transfers are permitted, and within what timeframe, is an organiser policy decision that should be stated in the registration terms. In Evenio, a transfer is handled by updating the attendee record to reflect the new delegate’s details, generating a new confirmation and QR ticket for the replacement, and invalidating the original.