Retired-processor refund access sheet
Retain the instructions and owners needed for refunds on old collections.
No signup. Enter reference codes, add records and download a CSV. Entries stay in the browser tab. Filled fields do not establish completion, approval or compliance.
| Old account reference | Original payment reference | Approved or submitted refund status | Provider funding instruction | Authorized access role | Closure instruction reference | Unresolved test or action |
|---|---|---|---|---|---|---|
| Old-provider-example | Payment-example-3 | 150 approved, not submitted | Written instructions requested | Bookkeeper-role | Support-case-example | Confirm access after closure |
- Starting records are fictional examples, not merchant evidence.
- Keep private documents and actual contacts in your approved business system. Use internal reference codes here.
- Missing required fields indicate an unresolved record. Filled fields do not prove authorization, completion, compatibility or compliance.
- Export to approved business storage. Browser edits are cleared on reload.
Before closing a repair-shop merchant account, establish how refunds on old payments will work. The new terminal does not automatically control money collected through the retired processor. Get written instructions, retain authorized access and reports, and assign someone to unresolved refunds. Schedule the closure around those obligations rather than the date the replacement device arrives.
Use with this guide
repair processor changeover checklist
Use the repair processor changeover checklist for the surrounding payout and balance handoff.
account and equipment obligations
The account and equipment obligations guide keeps refund access separate from device returns and cancellation notices.
Browse the complete auto repair guides and worksheets.
List the old payments still requiring attention
When preparing to close out old payments from repair orders, start with open orders, deposits, approved refunds, unresolved disputes and recently completed jobs with a pending payment correction. Use internal references to these instead of copying customer information to a spreadsheet or public worksheet. Record the original transaction ID and amount from the processor for each payment.
Separate an expected refund from an approved refund and a refund already submitted. Each needs a different action. A customer asking about a credit does not prove the shop owes a particular amount, and an owner approving the amount does not prove the processor has sent the money. Retain the commercial decision and the payment status as separate evidence. Use the repair processor changeover checklist for the surrounding payout and balance handoff.
Get account-specific closure instructions
Ask the retiring provider who retains refund access, how long access remains available, which funding source covers refunds and which reports remain downloadable. Record the support case or written response. Do not rely on a salesperson’s general description of month-to-month processing. Processing cancellation, equipment return and access to historical payment records might have different procedures and dates.
Stripe provides a useful example of why the details matter. Its refund documentation states refunds use the available Stripe balance and return to the original payment method. Insufficient available balance affects refund status. Those statements explain Stripe’s process, not the exact terms of every merchant account. Your worksheet should contain the instructions from the provider holding your original transactions.
Sources for this section: Stripe: refund destinations, funding, statuses and failures
Test the handoff before removing access
Complete the refund-access worksheet for each old account reference (e.g. contract ID) and list out the original payment reference(s), refund status, funding details, access owner and their closure process, and any other outstanding test cases. Verify with the old provider’s approved procedure that the staff member assigned to find the payment and view the status of the refund(s) for that account reference can complete this task. Do not test out refunding a live customer’s payment just to test out viewing the status of a refund on the screen.
Consider a fictional shop with three approved refunds of $150, $300 and $500 on its old account. The approved total is $950. The bookkeeper still needs to identify which refunds have been submitted, whether they succeeded and how the remaining amount will be funded. A $950 planning figure is not an instruction to send another $950. Submitted and completed amounts must remain visible to avoid duplicates.
Close the account without losing the audit trail
Store all permitted reports in controlled business storage (such as Office365 OneDrive, GoogleDrive etc) while access is permitted. The reports saved should include original payment references, refund references, provider status and any related payout information. Ensure that the export from the software does not contain full card numbers or security codes. Test the report is saved correctly and that all identifiers are saved for the bookkeeper.
Set an internal review date for any outstanding cases and the support route of the old provider. Be clear within your business which account a refund is to be processed from for old payments. Ensure the new processor does not process re-imbursement requests for payments collected elsewhere than through the new terminal. Check final debits and any outstanding records against the saved instructions with the old provider’s support team. Only mark a case complete if the payment evidence and customer balance agree. The account and equipment obligations guide keeps refund access separate from device returns and cancellation notices.
Primary sources
BlueFinch last reviewed these sources on October 4, 2026. Payment rules and state requirements can change.
Use this page for general business information. It is not legal, tax, or accounting advice.