Loading
Payments Agent
Paid on the call.Before the intent cools.
It points the customer at the payment path you already run, or takes the payment inside the conversation through hosted checkout. Card details go to the processor, never through Stomeji.
The problem
They meant to pay.Then the day happened.
Intent has a short shelf life
Someone ready to pay right now will pay right now. Ask them to log in later and later stops arriving.
The payment path has too many steps
Find the invoice, find the portal, reset the password, find the card. Each step loses people who genuinely intended to pay.
Taking card details by phone is a liability
Read out loud, written on a pad, typed into a screen that was never meant to hold them. That is a risk nobody wants to own.
How it works
01
It confirms the amount
Read from your billing system, stated clearly before anything else happens.
02
It sends the path
A hosted checkout link on the channel they are already on.
03
They pay the processor
Card details go straight to your processor. Nothing sensitive touches us.
04
It reconciles
The payment is confirmed, receipted, and written back to the account.
What you get
The whole job done,not a demo of it.
Card data never touches Stomeji
Payment happens on your processor's hosted page. We pass a link and read back a status, and no card number enters our systems at any point.
Your processor, your rates
It uses the payment provider you already have. No new merchant account, no change to your pricing, no new party in the flow.
Paid in the conversation
The link arrives on the channel they are already using, while they still want to pay. No portal, no login.
The amount comes from your ledger
It reads the balance rather than accepting a figure from the conversation, so nobody pays the wrong number.
Works with Support and Billing
Whenever another agent reaches a point where paying is the answer, this one handles it and hands the thread straight back.
Reconciled automatically
Confirmation, receipt, and the write-back to the account happen without anyone rekeying a reference number.
In action
A payment, taken in the thread.
Pick a reply or type your own. Note what it never asks for.
Live
SMS · Invoice 2214
Your balance on invoice 2214 is $1,240. You can pay here in a minute, and I’ll send the receipt as soon as it clears.
paypal.com/checkout/…
paid, thanks
Received. $1,240 posted to invoice 2214 and your receipt is on its way. You’re all caught up.
Hosted checkout
$1,240.00
Invoice 2214 · subscription + late fee
Pay with PayPal- Card details entered on PayPal’s page
- Card number never stored here
- Ledger updated when it clears
Sample workspace · Names and figures are illustrative
Specifics
Where it runs.
On your processor and your ledger. Optional, and off until you switch it on.
- Channels
- Voice, SMS, WhatsApp, email, web chat
- Processor
- Yours, unchanged
- Card data
- Hosted checkout only, never through us
- Amount
- Read from your billing system
- Reconciliation
- Automatic write-back with the receipt
- Status
- Optional add-on, off by default
Do you store card numbers?
No. Payment happens on your processor's hosted page. A card number never enters our systems, which is what keeps the compliance burden where it already sits.
Do we need a new payment provider?
No. It works with the processor you already use, at the rates you already have.
Can it read card details out over the phone?
It never asks for them and cannot accept them. On voice it sends a link to the same hosted checkout.
What if the payment fails?
It tells the customer plainly, offers to send the link again, and logs the failure on the account so your team can see it.