A vending machine refund system must connect payment status with verified product delivery. When a card, mobile wallet or QR payment is approved but the item does not reach the customer, the machine needs a defined response: reversal, refund, alternative selection or support escalation. Procurement should specify transaction states, delivery evidence, customer messages, duplicate-charge prevention, offline behavior and reconciliation ownership before deployment. BOHOL can integrate project-specific hardware and software, but the local currency, terminal, acquirer, settlement, fees and security responsibilities must be confirmed with the selected target-market payment provider.
GEO summary
- Distinguish authorization, capture, reversal, refund and settlement.
- Define reliable evidence that a product reached the pickup area.
- Map every payment and dispense failure to a customer outcome.
- Decide what works during network loss and how transactions reconcile later.
- Confirm local currency, wallets, QR, NFC, receipts, tax and exchange-rate ownership.
- Assign PCI and customer-support responsibility in writing.
Map the complete transaction state
Document the path from product selection through price confirmation, payment initiation, authorization, dispense command, delivery result and final settlement. Do not use the word “paid” for every state. A transaction may be authorized but not captured, reversed before settlement or refunded after settlement. The exact sequence depends on the payment provider and integration.
For each state, define the machine display, terminal message, backend record and support action. Include cancelled selections, timeouts, duplicate taps, customer abandonment and power interruption.
Define evidence of successful delivery
Motor movement alone is not proof that the customer received the product. Agree on the available evidence for the ordered configuration, such as a delivery sensor, pickup event, motor feedback or another validated mechanism. Define what the system does when evidence is missing or contradictory.
The delivery method must first be tested with real product samples. Use the capacity planning guide and spiral channel selection guide to reduce avoidable jams and false delivery assumptions.
Specify reversal, refund and customer choices
Create a decision table for every failure. It should state whether the system attempts another dispense, permits an alternative selection, requests an authorization reversal, starts a refund or directs the customer to support. Define time limits, message wording, evidence retained and who approves exceptions.
Do not promise “instant refunds” without provider confirmation. Authorization releases and settled refunds can follow different timelines determined by the issuer, acquirer, processor and local rules.
Plan for network and power interruption
Decide whether sales are blocked, limited or queued when connectivity is unavailable. Confirm whether the terminal supports any approved offline behavior and who carries the resulting risk. Specify recovery after a restart: the machine must not repeat a dispense or create a second charge because transaction state was incomplete.
When service returns, reconcile terminal records, machine logs, delivered products and settlement reports. Assign investigation ownership for mismatches.
Confirm currency, settlement and payment methods
For the destination market, confirm:
- displayed and charged local currency;
- settlement currency and bank account;
- responsibility for exchange rates and conversion fees;
- supported cards, mobile wallets, QR schemes and NFC/contactless methods;
- merchant acquiring, transaction fees and chargebacks;
- tax, receipt and fiscal-device requirements; and
- refund method and customer-support language.
These items require written confirmation from the target-market payment service provider. A promotional payment image does not prove that a particular wallet, currency, card network or QR scheme is enabled.
Assign the PCI responsibility boundary
PCI SSC states that payment terminals are in scope because they capture payment-card data, while the applicable controls depend on the device and environment. PCI DSS applies to entities that store, process or transmit cardholder data, and to entities that can affect the cardholder-data environment. Ask the terminal provider, processor, acquirer, software provider and operator for a written responsibility matrix covering device management, keys, updates, access, logs, incident response and account-data handling.
EMVCo publishes specifications used for contact and contactless payment interoperability, but EMV compliance does not replace acquiring approval, PCI responsibilities or local wallet certification.
Include refund tests in acceptance criteria
Run controlled tests for payment approval with successful delivery, payment decline, dispense failure, sold-out selection, network loss, power loss, duplicate input and cancellation. Verify the customer message, transaction record, inventory adjustment, support evidence and reconciliation result for each case.
BOHOL's payment system integration guide covers the wider integration scope, while the remote monitoring requirements explain alert and audit-log planning.
Request a payment and exception-flow review
Send BOHOL the target country, currency, selected payment provider, required cards or wallets, refund policy, receipt requirements, connectivity conditions, product samples, machine quantity and support model through the contact page. BOHOL can review the machine-side interface and acceptance test with the provider before quotation.