Accepting crypto, ACH and wire payments without losing track of orders

Decide what you accept, then say it the same way everywhere

Every payment method you accept is a promise to reconcile it. Before adding one, decide who will check it and how often. Then publish the details in one consistent format so buyers cannot get them wrong.

The payment code is the common thread. Whatever the method, the buyer is asked to put the order's code where the receiving side will see it: the memo, the reference field or the check memo line. The payment instructions generator turns your methods into copy you can paste into a confirmation page or email.

Crypto: the network is part of the address

Most lost crypto payments are not theft. They are a buyer sending the right coin on the wrong network, or the wrong coin to the right address. A USDC address on one network is not the same destination as USDC on another. Treat the network as part of the payment details, never as a footnote.

• Show the coin and the network together: "USDC on Ethereum (ERC-20)", not "USDC".
• Show the full address in a monospace font and give a copy button. Nobody should retype 42 characters.
• Say how you handle price changes for volatile coins. Most suppliers quote stablecoins only, which removes the question.
• Record the transaction hash with the payment. It is the only reference that proves the payment happened and where it went.

Crypto payments rarely carry a memo, so the code rarely travels with them. Ask buyers to reply to the confirmation email with the transaction hash, and match on amount plus that reply. It is one extra step for the buyer and it saves an hour of chasing.

ACH and wire: fees and truncation

Bank transfers bring two recurring surprises. First, names are truncated: a sender line might read "J GARC" or the name of a business the buyer owns. Second, wires often arrive short because an intermediary bank took a fee. Both are normal, and both need a rule you decide in advance.

• Match by the payment code in the reference field first, then by amount and a partial name.
• Decide a small tolerance for wire shortfalls, for example up to $25, that you absorb rather than chase. Record the shortfall so your books match the bank.
• Anything outside the tolerance becomes a partly paid order with the balance shown, not a paid order.

One ledger for every method

The single most useful thing you can do is keep one list of payments received, regardless of method. Each row carries the method, the amount, the date, who sent it, the reference and, once matched, the order. From that list three things fall out:

1. An order's payment status is the sum of its matched payments compared with its total: unpaid, partly paid, paid or overpaid. Nobody sets it by hand.
2. Refunds are payments with a negative amount on the same order, so a refunded order reads "refunded" without anyone editing it.
3. Revenue by method is a simple total, which tells you which methods your buyers actually use and what each one costs you.

Duplicates are the enemy of a shared ledger. Use each bank or chain reference as a unique key so the same payment cannot be recorded twice by two people or two imports.

Importing statements instead of typing

Most banks and exchanges export activity as a CSV file. Importing that file once a day is faster and more accurate than typing payments in.

1. Download the day's activity as CSV.
2. Map the columns once: date, amount, description or memo, reference.
3. Skip money going out. Only incoming payments belong in the ledger.
4. Let the import skip rows whose reference is already recorded, so importing the same file twice changes nothing.
5. Review what the import matched and what it left for you.

Know what each method costs you

Methods that look free are not always free, and card processing for this category is rarely cheap. Keep a simple table of the percentage and fixed fee for each method and let your ledger estimate the monthly cost. It often shows that a small discount for bank transfer pays for itself.

Keep a backup method ready

Card processing in this category can pause with little notice. Suppliers who already have bank transfer and at least one other method set up, with instructions buyers have seen before, lose days instead of weeks when that happens. Set the backup up now, even if few buyers use it today. The processor approval checklist lists what a new card processor will ask to see, so you can keep that file current as well.

A daily routine that takes ten minutes

1. Import or forward yesterday's bank activity and wallet transfers into one list.
2. Let every payment with a valid order code match itself, and check the few that did not.
3. Look at partly paid orders and send the buyer the exact balance and the same code.
4. Look at overpaid orders and decide: refund the difference, or hold it as credit with a note.
5. Release fully paid orders to packing, and nothing else.

Doing this every morning, rather than when the list gets long, is what keeps it at ten minutes. A week of unmatched payments takes an afternoon to untangle, because buyers have started following up and some have paid twice.

Refunds on bank and crypto payments

Refunds on these methods are manual, so write down how you handle them before the first one arrives:

• Refund to the same method and the same account or address the money came from, never to a new one a buyer sends by message.
• For crypto, refund the dollar amount received, in the same stablecoin, and record the network fee as your cost or the buyer's according to your policy.
• Record every refund as a negative payment on the original order, so the order shows as refunded and your totals stay right.
• Keep the transaction reference with the refund. It is the only proof you have if the buyer says it never arrived.

A buyer asking for a refund to a different wallet or account is the most common shape of payment fraud in this category. Your written rule is what lets staff say no without escalating.

Doing it in Purity

Purity keeps one payment ledger for every method you switch on, shows buyers the right details for each (including the coin network), puts the payment code on every order, imports bank CSV files without double counting, and shows money in and estimated fees per method each month. Order status updates itself from the payments. See it on a demo.