- Client
- EZ Visa Consultant
- Industry
- Immigration consultancy
- Where
- United States
- Built with
- WordPressStripeTelegramManaged automation engine
- From payment to files in the buyer's inbox
- 0.72 s
- Human touches per card sale
- 0
- Hours the store can fulfill
- 24/7
- To approve a payment made outside the card checkout
- 1 tap
We wired WordPress, Stripe, and a Telegram assistant together so the EZ Visa Consultant store charges, verifies, and delivers without anyone having to keep an eye on it.
How a purchase travels through the system
Two paths. The card one never touches anyone on the team; the other comes down to one button.
Card payment path: the buyer purchases in the WordPress store, Stripe confirms the payment, the system verifies the notification genuinely came from Stripe, sends an email with the files and the access code, and delivery completes in 0.72 seconds with no human involvement.
- 01Purchase in the store
- 02Payment confirmed
- 03Automatic verification
- 04Email with files and code
- 05Delivered
From payment to files in the buyer's inbox. With nobody on the team doing anything.
Where it started
EZ Visa Consultant is a consultancy that, alongside its main service, sells digital material from its own WordPress site. The site existed. Card payments existed. The files existed. What did not exist was anything connecting them.
Every sale ended in something a person had to handle by hand: log in, check, find the file, write the email. And when a buyer paid through a peer-to-peer payments app, which is common in their audience, the work doubled. A screenshot of the payment arrived by message, someone had to review it whenever they could, and only then send the materials.
That model works at three sales a month and breaks at thirty. Worse: while nobody is watching, there are no sales. The business could only sell during the hours somebody was available to fulfill.
The store was not set up to grow, either. Every new product meant repeating the same manual work from scratch.
The pieces we connected
There was no need to switch platforms or rebuild the site. Everything rests on tools the business already had, or recognizes without needing an explanation.
WordPress is the store. The catalog, the product pages, and the purchase confirmation page live there. It stays theirs and keeps working the way it always did, with the difference that it is now the start of a process rather than the end of one.
Stripe is the cash register. It takes card payments and, the instant a payment is confirmed, it notifies the automation engine. That notification is the trigger for everything else.
A Telegram assistant is the command post. When someone pays outside the card checkout, the receipt lands in the team chat with the purchase details already laid out and two buttons. Approve or reject. There is no dashboard to learn, no session to start, no new app to install. It is the same Telegram they already used.
The automation engine is the part nobody sees, and it is the real work: it listens to Stripe, validates, decides, composes, and sends. It runs on our infrastructure, monitored, and it is the one thing the team does not have to administer.
Transactional email closes the loop, carrying the business's own visual identity rather than some generic tool's.
The result
When someone pays by card, nothing happens
That is the result: nothing happens. Nobody gets a notification to handle, nobody hunts for a file, nobody writes an email. The buyer pays on the site and their files show up in their inbox with an access code of their own, along with the bonus materials.
Measured end to end: 0.72 seconds. The agreed target was to stay under 60.
When someone pays another way, it is one button
The buyer uploads their receipt on the site, through a form carrying the business's identity. The team gets the purchase and the receipt laid out in Telegram, and decides with their thumb.
If they approve, the exact same automatic delivery fires. If they reject, the buyer gets a clear notice that the payment could not be verified. Either way the team gets a confirmation back with the outcome, the product, and the code issued, so they know not just that the decision was recorded but that the email actually went out.
In the original conversation, this was the flow that ate the most time. Today it is one tap from a phone.
The numbers
| Before | After | |
|---|---|---|
| Time until the buyer has their files | Hours or days, depending on availability | 0.72 s |
| Human touches per card sale | 1 | 0 |
| Effort to approve an alternative payment | Review, find files, compose, and send | 1 tap |
| Hours the store can fulfill | Whenever somebody is available | 24/7 |
| Visibility when something breaks | None | Filtered email alert |
| Automated payment methods | 0 | 2 |
Other figures from the system:
- 5 files are delivered with every purchase: the product bought plus the bonus materials.
- 58.6 MB is the largest bundle in the catalog. We measured the download at 23.6 MB/s, roughly 190 Mbps, which puts it at 2.6 seconds end to end. We verified the server was not the bottleneck before suggesting any change.
- 14 days of automatic receipt retention in the engine. The permanent copy lives in the team's Telegram chat. We documented that explicitly instead of leaving it as an assumption.
What the system guarantees
A flow that works when everything goes right is not a deliverable. This is what the team has covered without having to think about it:
Nobody can give themselves a free product. The payment entry point is protected twice over, including cryptographic verification that the notification genuinely came from Stripe and not from someone who guessed the address. We tested it by forging a payment: it delivers nothing.
The receipt form is not an open door. It accepts four file types only, with a size cap, a per-person and per-minute submission limit, and an extra brake at the network edge. Anyone who goes over gets stopped before reaching the team's Telegram and, deliberately, without learning that they were stopped.
Alerts tell noise apart from problems. The system speaks up when a delivery genuinely fails, but not when it rejects something it is supposed to reject. If someone tries to abuse the form, the inbox does not flood. Everything is still logged.
Delivery does not depend on text matching. In a test purchase, the product name arrived from Stripe with a different typographic dash than the catalog used. A system matching on text would have failed silently. Ours identifies the product by its identifier and never noticed the problem.
The email looks right even where email looks wrong. The templates carry three layers of dark-mode protection, because every mail app implements it differently. We documented honestly the one specific case where that protection is not enough, instead of promising it works everywhere.
How the work ran
- Discovery by phone to understand the business before proposing anything.
- A working prototype before the client spent a cent, so they saw the result instead of imagining it.
- Scope closed and written down. Anything outside it was quoted separately, with no exceptions and no friction.
- A full backup before touching the site.
- Seven calendar weeks, with the bulk of the work concentrated in a handful of sessions.
What the team no longer does
They do not check email to find out whether they sold. They do not hunt for files. They do not reply "sending it over now." They do not lose a sale because they were busy, asleep, or traveling.
They approve a payment with their thumb, whenever it arrives, from wherever they are. The rest is already done.
How these figures were measured
The 0.72 seconds and the other figures come from end-to-end validation of the system, with events signed by Stripe's servers and using the store's real checkout. They are not estimates or brochure promises: they are measurements taken on the system that was installed.
Do you sell something digital and still deliver it by hand? That gets automated, and it usually costs less than what you are losing in time.