Zelle doesn’t have an API. Neither does CashApp in any meaningful sense for what we needed. If a customer sends a payment, there’s no webhook that fires, no event we can subscribe to. The only signal that a payment happened is an email notification.
For most businesses, this means someone is manually checking an inbox, matching payments to orders by hand, and updating records in a spreadsheet. We wanted to make that automatic inside Administry — zero manual steps, real-time matching, payment reflected in the order the moment it lands.
The challenge is that payment notification emails don’t contain enough structured information to reliably match them to a specific order. The sender name might not match what’s on file. The amount might be split or partial. The memo field, if there is one, contains whatever the customer typed — which could be anything or nothing.
The ref code system
We solved the matching problem with a reference code. When a customer chooses Zelle or CashApp at checkout, they’re assigned a unique four-digit code that’s valid for 24 hours. The payment instructions tell them to include it in the memo. When the notification email arrives, we parse for that code and match it to the open order.
Four digits feels small. In practice, with a 24-hour window and a per-order code, collisions are rare enough to be a non-problem. And because the code is short, customers actually type it. Longer codes get skipped.
When a payment comes in with a valid code, it’s matched automatically. When it comes in without one — or with a code that’s expired — it goes into a review queue where a human can match it manually. We handle over, under, and exact amounts differently: exact closes the order, over flags it for refund, under marks it as partial and sends the customer a follow-up.
The detection side
The matching logic only works if we know about the email the moment it arrives. Not on a polling schedule. Not with a 5-minute delay. Now.
Most email platforms have webhooks you can configure for inbound mail. The one we use had that feature — behind a plan tier we weren’t on. After some digging, we found an equivalent mechanism that was free, fired at the exact moment an email was received at the SMTP level, and didn’t require upgrading anything. We wired it to an internal endpoint and the whole thing went live.
The latency from payment notification email landing to order status updating is under 200ms. That’s fast enough that customers often see their order confirmed before they’ve put their phone down.
What we learned
P2P payments feel hard to integrate because there’s no official API. But the payment notification email is actually a reliable enough signal if you structure the matching correctly. The ref code does the work that an API would normally do — it’s just a constraint you put on the transaction at the point of sale instead of at the point of receipt.
It’s not as clean as a Stripe webhook. But it works, and it works well enough that we’re not sure we’d do it differently even if an API existed.