Reviewed October 17, 2026. This practical guide replaces an earlier general overview. The original publication date and URL are retained.
A wallet payment can be easy to accept and difficult to investigate when a customer presents a different identifier during a return. Build the refund trail before adding another wallet button.
Start with an order-to-payment map
Give each order an internal reference and retain the processor’s payment reference, capture status and refund history. Store the payment method category separately from any masked account display. A receipt’s last four digits alone should not become the sole matching key. Ask the provider which identifiers its staff can safely use when a customer’s wallet and physical card display differ.
Rehearse a partial-return scenario
Use a controlled test order containing two items priced at $45 and $30. After capturing $75, refund the $30 item through the original payment record. Verify that the order shows $45 retained revenue, one refund reference and the correct inventory adjustment. Check the processor report and the eventual deposit reconciliation independently; a button showing success is only one checkpoint.
Give support a bounded lookup procedure
Staff should request the receipt or order reference first, then use approved lookup fields. Escalate unresolved matches instead of creating a new payment to reverse the old one. Include a case owner and next customer update time. Test the procedure with an employee who did not configure the wallet integration; an expert operator can conceal a confusing workflow.
Keep token security separate from refund evidence
EMVCo describes payment tokens as substitutes for account numbers with constrained use. That security design does not supply the merchant’s entire order history. Never ask a customer to email full card credentials to solve a matching problem. Retain only the permitted operational evidence and use the processor’s secure tools for the payment action.
Sources and next steps
Primary reference: EMVCo payment tokenisation overview. The worksheet and examples above are operational analysis, not reported customer results.
Continue through the AMS Florida merchant reading path. For the broader framework, explore Eric Kuvykin’s fintech, payments, alternative financing and AI topic guides.
