Why Zelle payments go missing
A card payment is born attached to an order. The checkout creates the order, the processor charges the card, and the two records point at each other. A Zelle payment is the opposite. The buyer leaves your site with an order number on the screen, opens their bank app, and sends money to an email address or phone number. Your bank records a sender name, an amount and a memo. None of those fields has to match anything in your store.
In practice four things go wrong, over and over:
- The name on the bank account is not the name on the order. A buyer orders as "Jordan" and pays from a joint account in their partner's name, or from a business account.
- Two orders share an amount. Ten buyers ordering the same kit on the same day all owe the same number, so the amount alone proves nothing.
- The memo is empty, or says "thanks", or carries the order number from a different order.
- The alert email sits in one person's inbox. Nobody else can see the money arrived, so the order stays "pending" and the buyer gets a reminder for an order they already paid.
Every one of those is a matching problem, not a payments problem. The money arrived. The store just cannot tell which order it belongs to.
Step one: give every order its own payment code
Order numbers are a poor thing to ask buyers to type. They are often long, they sometimes repeat across systems, and they look like any other number in a bank memo. A payment code is built for one job: surviving the trip through a bank app.
- Short. Six characters after a fixed prefix, such as PUR-7K3Q9M, fits in every memo field and is easy to read aloud.
- Unambiguous. Leave out 0, O, 1, I and L so a hurried buyer cannot type the wrong one.
- Unique per store. The code identifies one order and nothing else.
- Shown everywhere the buyer looks: the order confirmation page, the confirmation email and every payment reminder.
Put the instruction next to the code, not in a paragraph below it. "Send $98.00 by Zelle to payments@yourstore.example and put PUR-7K3Q9M in the memo" is one sentence a buyer can follow on a phone. Our payment instructions generator builds that block for each payment method you accept.
Step two: give every payment a place to land
Most banks send an email when a Zelle payment arrives. That email is the fastest signal you will get, and it is the thing to capture. The goal is that no payment exists only in someone's inbox.
- Set up a dedicated address for payment alerts, separate from your support inbox.
- In your bank's alert settings, turn on "payment received" or "Zelle received" alerts and send them to that address. If your bank will not send to a second address, forward them with a mail rule.
- Record each alert as a payment the moment it arrives: date, amount, sender name, memo and the bank's reference number.
- Use the bank reference number to ignore duplicates. Banks resend alerts and mail rules double-fire; the reference stops one payment being counted twice.
If you only do this part, you already have a single list of every payment received, which is more than most small suppliers have. The next step turns that list into paid orders.
Step three: match in order of confidence
Matching works best as three passes, from certain to uncertain:
| Pass | Rule | What happens |
|---|---|---|
| 1. Code | The memo contains an order's payment code | Mark the payment matched and update the order |
| 2. Amount and name | Exactly one open order has the same amount owed and a customer whose last name appears in the sender name | Suggest the match; a person confirms |
| 3. Everything else | No code, several possible orders, or none | Leave it in a "to be matched" list |
The second pass is a suggestion, never an automatic match. Two buyers named Garcia ordering the same kit is common enough that you want a human to glance at it. The point is that the human is picking from one suggestion, not searching a bank statement.
Partial payments deserve their own rule. If a buyer sends $40 against a $100 order, the order should read "partly paid, $60 owed", not "paid" and not "unpaid". Shipping only when the balance reaches zero is a decision you make once, not a judgment call every time.
Step four: a ten-minute daily pass
Automation handles the easy majority. The daily pass handles the rest.
- Open the "to be matched" list. For each payment, confirm the suggestion or pick the order.
- Mark transfers between your own accounts and refunds you sent as "not an order" so they stop appearing.
- Scan orders unpaid for more than three days. Anything with no payment gets a reminder that repeats the code and the amount.
- Close orders that have been unpaid past your cut-off. An order that sits unpaid forever distorts your stock counts and your revenue numbers.
Ten minutes a day is the whole job once the codes and the alert capture are in place. Without them, the same work is an hour of searching a bank app every few days.
Reminders that get paid instead of ignored
A payment reminder has one job: make paying easier than ignoring it. That means the reminder carries everything the buyer needs and nothing else.
- The amount still owed, not the order total, if they have paid part of it.
- Where to send it, for each method you accept.
- The payment code, with the instruction to put it in the memo.
- When the order will be closed if it stays unpaid.
Two reminders is usually enough: one at 24 hours and one at 72. After that, closing the order and releasing the stock is better for everyone than a third message. Keep reminders to buyers who have not opted out of texts, and send texts only at reasonable local hours.
What to track so you know it is working
- Share of payments matched by code. This should climb above 80 percent once codes are on every page and email. If it does not, the instruction is not visible enough.
- Payments waiting to be matched at the end of each day. The target is zero.
- Orders unpaid for more than three days, and their total value.
- Orders closed unpaid each month. A rising number usually means a checkout step is confusing buyers, not that buyers are flaky.
Doing it in Purity
Purity puts a payment code on every order, shows buyers where and how to pay at checkout and in every email, and gives each brand a private address for forwarded payment alerts. Alerts from the common banks and payment apps become payments on their own, matched by code or suggested by amount and name. Everything else waits in one "to be matched" list, and unpaid orders get reminders and close on the schedule you set. See how it fits your store on a demo, or read the features.
Common questions
- Can Zelle payments be matched to orders automatically?
- Yes, if every order carries a short payment code and buyers put it in the memo. Forwarded bank alerts can then be read and matched by that code. Payments without a code need a quick human check before they count.
- What if a buyer forgets the code?
- Match by the exact amount still owed plus the customer's last name appearing in the sender name, and treat it as a suggestion a person confirms, never as an automatic match. Two buyers with the same surname and the same order total happen more often than you would expect.
- Should I ship before the payment is matched?
- No. Ship when the order reads fully paid. If a buyer sends proof of payment, find the payment in your bank alerts and match it; a screenshot alone is not a payment.
- How long should I wait before closing an unpaid order?
- Most suppliers use five to seven days with two reminders in between. Closing releases the stock and keeps your numbers honest; the buyer can always place a new order.