Decide what each record represents
Begin with a sample order and list the identifiers created by your own system and by the service provider. Your team should be able to connect an order, its payment result and the relevant settlement record without guessing from a customer message. Ask the provider which reports are available and what each status actually means.
Keep operational measures separate. A checkout attempt, a confirmed payment, a refund request and a completed refund are different events. Use names that describe the evidence you have rather than a general label such as ‘processed’.
Define an exception queue
Agree how records that do not match will be investigated. Assign an owner, an initial review point and an escalation route. A shared sheet can be enough for an early pilot if access is controlled and the fields are consistent. Avoid copying unnecessary personal or financial information into it.
- Internal order reference and provider reference
- Observed status and the source of that status
- Amount, currency and relevant reporting period
- Current owner, next action and resolution evidence
Rehearse the refund conversation
Ask what the provider needs to investigate a refund, how its progress can be checked and which party communicates with the customer. Test a sample case with finance and support before launch. Document how corrections appear in later reports so a team member can understand a reopened issue. Review a small batch together at the end of the pilot; a clean dashboard should be backed by records your team can trace.
Your working checklist
- Connect records with stable references
- Use precise operational statuses
- Assign exception owners
- Review traceable evidence at pilot close
Editorial note
Use the original publications for their current scope. These guides offer an editorial framework; they do not certify a supplier or replace business-specific checks.
