Failed Payment, Failed Service & Refund Workflow
Record the failed customer outcome, machine event and payment status before assigning refund and recovery work. A completed service or refund is recorded from the failed customer outcome, the machine event and the payment status.
Describe the failed customer outcome precisely
Separate a declined payment, an authorised payment without a completed delivery, a partial service and a customer who cannot collect the result. Identify the machine, time and relevant transaction reference without asking the customer to disclose payment credentials. A machine alert and a payment-provider status may describe different parts of the same session. The workflow should establish what happened before someone promises a refund, repeats a charge or restarts the equipment.
Check the transaction and the machine result first, then handle the refund and the equipment recovery separately.
Payment Integration Verification Matrix — Input to the evidence step: record the provider and machine combination for this failed session, including the failed transaction, the refund path and reconciliation, before an authorised refund.
Test the proposed configuration with controlled cases
Use the agreed test procedure to observe a successful session and representative exceptions. For vending, include a failed release and collection issue where applicable. For service equipment, define what counts as an incomplete session and what evidence the operator can see. Record the expected result, actual machine response, payment status and follow-up action.
Keep each unsuccessful observation in the acceptance record with its expected result, machine response, payment status and follow-up.
Assign refund and recovery responsibilities
Ask who can review a transaction, authorise a refund and communicate with the customer. Identify which actions occur in the payment service and which are available through the equipment system. Treat equipment recovery separately. Follow the model's documented procedure and identify conditions requiring a local inspection or qualified technician. Do not describe an available remote restart as proof that the underlying fault has been resolved or that the equipment is ready to resume operation.
The payment check and the equipment recovery are separate sequences. Refund eligibility and timing follow the existing operating arrangement.
Name the refund owner and the recovery owner separately, and record the decision once.
Payment Options & Country Compatibility Review — Input before an authorised refund: the country and merchant arrangement, a completed cycle, and the exception where a charge has no completed delivery.
Remote Monitoring: Functions to Verify — Next step when recovery uses a remote event: confirm the event is current and name the local team that responds. A restart stays separate from the refund.
Payment check
Equipment recovery
Close the loop with the operator and customer
Define the contact route shown at the site, the details needed to locate an event and the person responsible for follow-up. Track open cases until the relevant outcome is confirmed. Response time here is the fault-handling and support arrangement agreed for that operating model. Refund eligibility and timing follow the same existing arrangement. Automatic refunds and a universal remote repair capability stay outside the model record until the operating model names them.
Close the case only after the agreed outcome is confirmed with the operator and the customer.
Frequently asked questions
What to do if a vending machine does not dispense?
Record the failed customer outcome, time, unit and non-sensitive transaction reference, and use the contact route shown by the operator. Payment review, authorised refund work and safe machine recovery need named owners. A completed service or refund is recorded by its named owner, separate from a restart.
If the payment succeeded but nothing was dispensed, which record should be checked first?
Check the machine event and the payment-provider status for that session before a refund or a restart. They may describe different parts of the same session. Identify the machine, the time and a non-sensitive transaction reference, and do not ask for payment credentials. A payment success screen alone is not a completed delivery; compare the machine record with the provider record, then name who investigates the refund.
Can the refund and the restart be handled as one step?
Refund and restart stay separate steps. Authorising a refund is a payment-service action by the person named to review the transaction. Restarting the equipment is the recovery action. A remote restart is not proof that the fault is resolved or that the machine is ready, and the documented procedure still names when a local inspection or a qualified technician is required.
How do you avoid paying the same refund twice?
Record the refund decision once, with the evidence that links the payment reference to the machine event, and name the person allowed to authorise it. That record is how the team avoids applying the same correction twice. The completed refund stays with that owner, separate from any restart.