How refunds work in FaltaPay
FaltaPay has no refund screen of its own. You issue a refund from wherever the payment originally lived: the WooCommerce order, the ProfilePress order, the MemberPress transaction, and so on. FaltaPay hooks into each plugin’s own refund action, sends the refund to the gateway, and reports back to that same screen.
A refund always goes to the gateway that actually took the original payment, not whichever gateway happens to be switched on today. If you take a payment through HyperPay, later switch your store to Tap, and then refund that older order, FaltaPay still sends the refund to HyperPay, because that is where the money is. If the gateway that took the payment has since been switched off entirely, the refund is refused with a message telling you so, rather than silently going nowhere.
Issuing a refund
| Plugin | Where to refund |
|---|---|
| WooCommerce | Open the order and click Refund. See WooCommerce setup. |
| ProfilePress | Open the order and use its refund action. |
| MemberPress | Open the transaction and use its refund action. |
| Paid Memberships Pro | Open the order under Memberships > Orders and use its refund action. |
| LifterLMS | Open the order’s transaction and use its refund action. |
| Tutor LMS | Open the order and use its refund action. |
| GiveWP | Not available from Give’s donation screen in this version. Refund the donation directly from your gateway’s own dashboard. |
Every one of these except GiveWP supports a partial refund: enter an amount lower than the full total in the host plugin’s own refund form, and only that amount is sent to the gateway.
What reaches the gateway
A refund request carries the original transaction ID, the amount, and the currency, formatted to that currency’s own number of decimal places. This matters in the Gulf: Kuwaiti dinar, Bahraini dinar and Omani rial use three decimal places rather than two, so a refund amount is never rounded to the wrong scale before it is sent.
HyperPay refunds are sent as a back-office refund operation against the original payment; Tap refunds are sent against the original charge. A pre-authorised payment that has not been captured yet cannot be refunded, since no money has been taken to give back; your gateway declines the attempt if you try.
Where the record is written
There is no separate FaltaPay transactions table. Every plugin writes the outcome to its own record:
- WooCommerce and ProfilePress add an order note with the refunded amount and the gateway’s refund transaction ID.
- MemberPress marks the transaction refunded and sends its own refund notice to the member.
- Paid Memberships Pro marks the order refunded.
- LifterLMS and Tutor LMS record the refund against the transaction it belongs to.
If you need the raw gateway response behind a refund, turn on debug logging and check the Logs screen; a failed refund is always logged there with the gateway’s own error message, whether or not debug logging is on.
Capturing a pre-authorised payment
If your Advanced setting is Pre-authorise, capture later, FaltaPay holds funds rather than taking them immediately, and the order sits On hold until you capture it. There is currently no button in FaltaPay to do this from WordPress; you have to capture (or void) the authorisation directly from your gateway’s own dashboard. Refunding an order that was only authorised and never captured is not possible, since nothing was taken yet.
Troubleshooting
“This order has no FaltaPay transaction to refund.” The order was never successfully paid through FaltaPay, or the payment record was cleared some other way. Check the order’s notes for a FaltaPay transaction ID before trying again.
The refund fails with a message from the gateway itself. This is the gateway declining the refund, most often because the original transaction was already fully refunded, or because it is outside the window your gateway allows for refunds. The exact reason is in the message shown and in the log entry.
The order shows refunded in WordPress but the customer says they have not received the money. FaltaPay reports what the gateway told it. If the gateway confirmed the refund, the delay is on the gateway or the customer’s bank, typically a few business days; check the transaction directly in your gateway’s own dashboard if it has been longer than that.