Use this link to share with your colleagues:
How to Manage Complex Refunds: https://help.pm.leapevent.tech/a/1505020
As of the January 2022 release, users you designate with a special Permission Set can refund to a credit card even if there have been multiple payments on a Ticket Order. Having a staff member who can handle these kinds of complex refunds in PatronManager saves you time and expedites refunds for your patrons.
Because these kinds of transactions carry some additional risk and can require additional documentation for future audits, we strongly recommend designating one user (for example, your box office manager) to perform these refunds.
In this article, we'll cover:
- The risk involved with complex refunds
- How to mitigate that risk
- Assigning a designated user to handle complex refunds
- Processing complex refunds
- And a few FAQs
Let's jump in!
If you found this article due to the error message pictured above, make sure you've looped in the appropriate people at your organization to decide how to move forward.
What's the risk?
There are three main points, which we'll expand on further below:
- It's possible to accidentally over-refund a given credit card
- There is no way to undo a refund
- Elavon may flag your account for fraud review
Here's a bit more detail:
First, when performing a complex refund the designated user will be able to refund to any credit card that was used for a payment on that Ticket Order - even if the original credit card transaction was less than the refund amount.
Secondly, as with any refund, there is no "undo" option.
And finally, these kinds of refunds are treated as a freestanding "CREDIT" to the patron's credit card, rather than as a normal "REFUND" transaction. Processing multiple "CREDIT" transactions may cause your account to be flagged for risk review.
How can we mitigate that risk?
Here are some recommendations:
- Assign a single user to handle these kinds of refunds. This helps ensure that they're aware how often it's happening, and that they're carefully following your procedure.
- Review the risks outlined above with your finance team and with that designated user. Be sure everyone is on the same page regarding the circumstances when you'll process these transactions and the notes you want to keep when they occur.
- Process these types of refunds with careful attention; double-check that you're refunding the intended amount to the intended credit card.
- Enter clear notes in the Journal Notes field for these transactions. If you have to provide information to banks, your auditors, or the patron later on, these notes will be useful.
- Be sure to respond promptly if the bank requests more information from your organization.
Sounds good. How do we empower the designated user?
Once you've made a plan for how your organization will handle and track these kinds of complex refunds, and decided which user will manage them, it's time to give that user the power to do so!
1. Head over to Setup
2. Search for and click on "Permission Sets"
3. Click "Manage Complex Refunds"
4. Click "Manage Assignments"
5. To designate a user, click "Add Assignments"
6. Check the box next to the user you wish to designate, then click "Assign"
All set! The user is now able to handle complex refunds.
If you need to remove a previously designated user, check the box beside their name and click "Remove Assignments"
How do we process complex refunds?
You've assigned the Permission Set to your designated user - now what?
1. A user without the Permission Set asks for help
Users without permission to manage complex refunds will see an "Insufficient privileges" message if they choose "Credit Card" as a refund method on a Ticket Order that has had multiple payment transactions:
They should reach out to your designated user for assistance.
2. The designated user starts the refund
They will need to start fresh from the Ticket Order - they cannot pick up a refund in progress from another user.
3. Upon selecting "Credit Card", the user sees a warning and can choose a credit card to refund
The warning reminds the user that they're about to process a complex refund, which entails the risks outlined at the beginning of this article. They'll be able to choose a credit card to refund from a dropdown list.
4. The user chooses a credit card from the dropdown
The dropdown list shows a list of credit card payments that have occurred on the Ticket Order, with the date/time, amount, and credit card type for each.
You may only see one credit card transaction in the dropdown, for example if the rest of the Ticket Order was paid with cash. You will still need to select that credit card if you wish to refund to it.
5. The user double-checks what they're about to do, enters Journal Notes, and submits the refund
- Confirm that the refund amount is correct - this is the amount that will be credited to the selected card
- Confirm that the correct credit card is selected to refund - the amount that appears in the dropdown is the amount that was charged for the original transaction on that card
- Enter Journal Notes for future tracking and audit purposes
- Submit the refund
Frequently Asked Questions
If your organization is uncomfortable with the risks associated with these kinds of complex refunds, that's understandable. You can avoid processing them altogether as follows:
- Don't assign the "Manage Complex Refunds" Permission Set to any users in your organization. Without the Permission Set, these types of credit card refunds aren't possible
- When a Ticket Order has had multiple transactions, refund to cash, check, or gift card instead of credit card, or refund to Donation if the patron is willing.
The risk monitoring system uses a variety of parameters, such as the highest transaction amount, average transaction amount, and volume that the acquiring bank, such as Elavon, approved for your account. If your account exceeds expected amounts or volumes, for example, that can trigger an alert. The acquiring banks don't share exact details on their monitoring process, as that could in turn make it easier for a bad actor to avoid those thresholds.
In most cases, yes - typically an acquiring bank would launch an investigation and ask for documentation and information about the transaction(s) that triggered their alert. This might cause a delay in processing those specific transactions, but other transactions would normally be unaffected, as long as the organization responds promptly to their inquiry.
That said, acquiring banks do of course have discretion over their account handling, and it's always possible that a very large CREDIT transaction or a sudden spike in this kind of volume could cause them to react more strongly.
No. To reduce the risk of fraud, you can only refund to a credit card that was previously used on that specific Ticket Order.
Good question! The short answer is exchanges, but here are two scenarios to help clarify.
Backing out a previous exchange
Perhaps the patron purchased a $100 ticket using one credit card, then exchanged it for a $150 ticket and paid the $50 difference with a second credit card. Your designated user can choose to refund the full value of the new $150 ticket to either credit card previously used, but what if you want to refund $100 to the original credit card and $50 to the other credit card?
If you need to refund more specific amounts to each credit card and if there aren't currently items on the Ticket Order that correspond to those amounts, you'll need to process exchanges to back out the necessary amounts.
In the example above, you could exchange the $150 ticket for a $100 ticket (reversing what had happened previously and refunding the $50 difference to the second credit card), then refund the $100 ticket to the first credit card.
Backing out partial payments for the original Ticket Order
In the simplest scenario, a patron may have purchased two $100 tickets ($200 total), and paid $100 with one credit card and $100 with another credit card. In that example, you could simply process two separate refunds, of one ticket each, to the two separate credit cards. But what if the patron purchased one $100 ticket, but paid $50 with one credit card and $50 with another?
In that scenario, you would need to "break apart" that one ticket, and you can do that via an exchange. You may need to create a temporary Private Price Level (in this example, a $50 Price Level), and exchange the $100 ticket for that new $50 ticket, refunding the first credit card in the process. Then refund the new $50 ticket to the other credit card. If you created a new Price Level for the purpose, be sure to remove or deactivate it when you're finished to avoid confusion.
The dropdown you use to select the credit card to refund shows a list of credit card payment transactions, with the date/time, amount, and credit card type for each:
If this information isn't sufficient to decide which credit card to refund, you can find more detail about each transaction on the order detail page. Here's where:
1. Click on Order Info
2. Click "Show Details"
If there are a lot of items on the order, you may need to scroll down a little to find it.
3. Refer to the list of Payment Transactions
This list will show a little more detail about the type of payment, for example whether it was a partial payment or a transaction as part of an exchange.
No. Credit card transaction tokens are retained for 18 months. It is not possible to refund transactions older than that, even using this method, since the system relies on that token to process the refund.
For general reporting purposes, these kinds of complex refunds are the same as normal refunds.
If you need to find these specific kinds of transactions in PatronManager later, there is a checkbox field on the Payment Transaction that is checked when a refund is processed using the CREDIT function. The field is accessible in Payment Transaction reports (field name: "Refund Type = Credit"), and visible on the Payment Transaction record:
