Most people land here with one of three problems
Different starting points, the same fix: the payment stops being something a person has to handle.
Your staff are reading card numbers off the phone
Someone in accounts takes card details over a call and types them into a terminal. It works, it is how it has always been done, and it puts your business squarely inside PCI scope with people as the weakest link.
Card data out of your business entirelyYou are chasing invoices customers already want to pay
Credit control gets the customer on the phone, the customer agrees to pay, and then has to hang up, find the invoice, dial a separate number and key in a reference. Most do not. The willing ones are lost in the gap.
A link they can pay before the call endsSlow and manual reconciliations eating into staff time
Payments land in one system and orders sit in another, and somebody exports both and matches them by hand. Until they do, nobody can say with confidence what is actually paid.
Accounts reconciled automatically in real timeTwo ways in. One place to reconcile.
Your customer pays in a browser or pays on the call. Either way they see one clean page — no internal identifiers, no account exposure, and no card form for your staff to handle.By link
The link goes out on whichever channel your customer actually answers, and the card is entered on a page issued for that one order.
On the call
The customer pays before they hang up, through the phone system you already run.
Both routes end in the same place
However the customer paid, it is matched back to the order that raised it and shows as settled in your own system. There is no second process for phone payments and no separate set of figures to join up at the end of the week.
The same five stages sit behind both routes
| Stage | What moves | Who handles it |
|---|---|---|
| Order in | The customer, the amount and your reference | Your system |
| Record created | A customer record, with the order registered against it | Automated |
| Payment page issued | A secure page for that one order, on the processor’s own domain | The card processor |
| Paid | A tap-to-pay link by email, SMS or WhatsApp, or the card collected on the call | Your customer |
| Reconciled | The payment matched back to the order that generated it | Automated |
No row in that table needs a member of your staff.
The payment is one step. This is the rest of it.
Six things the platform takes off your team, from the systems you keep running to the figures that arrive without anyone building them.An AI assistant can take the payment
The payment is collected during the call, so the order is settled before the customer hangs up.
Nothing you already run gets replaced
No need to replace your CRM or billing platform. Your system of record remains your system of record, and we process payments on the information it provides.
No shortlist of supported platforms
We integrate through your existing business systems and APIs. There is no shortlist of supported platforms, and where the connection does not exist yet, we build it.
Your staff never take a card number
Payment workflows run between your systems and your payment providers, so staff time is not spent taking card details, chasing people who have already agreed to pay, or matching statements by hand.
See every transaction as it happens
Live dashboards show what has been issued, paid and reconciled across every system you run, updated as it happens.
Reports that arrive on their own
Daily, weekly, monthly or a schedule you set. The figures reach whoever needs them, built from the same records the dashboards run on.
We connect to your systems. We do not replace them.
Your CRM, billing platform or business software stays exactly as it is. The payment gateway reads what those systems already hold and processes payments against it. Where the join does not yet exist, our specialists build it, scoped to your deal rather than picked from a fixed menu.
The call can take its own payment
Two options, and you choose which. An AI assistant answers, confirms the order and takes the card with no agent on the line. Or a static dial-pad menu, where the customer keys the payment through themselves and nobody on your side hears a card number. Both run through your existing phone system, connected at extension level.
What ships with the platform
Everything below comes with it. The parts scoped per deal are called out further down.Hosted payment links
Secure, processor-hosted payment pages issued per order. Card details are captured on the processor’s page, never on yours and never on ours.
SMS-first delivery
Links go where customers actually respond. Email and WhatsApp are available alongside or instead.
Automatic reconciliation
Payments are matched back to the originating order on their own, so paid and unpaid status is accurate without anyone checking.
Split payment
A single order can be settled across more than one card payment, for a customer who wants to pay part of a balance now.
Link lifecycle management
Reissue a link when the amount changes and the one it replaces is cancelled, so a customer working from an old text cannot pay twice.
Customer reuse
One customer record spans many orders, so duplicate profiles do not build up over time.
Safe to re-fire
Sending the same order twice will not create a duplicate charge or a duplicate record.
Multi-tenant ready
Several companies or departments run as separate tenants on one deployment, each managed from a single admin account.
Want to see it running against one of your own invoices?
The work does not grow when the volume does
Most providers can take a card. What decides whether it works at your volume is how much human handling each payment still needs after it is taken, and whether the record stays accurate when the numbers get large.No ceiling to design around
Throughput is not bounded by how many payments a person can handle.
- Links issued, delivered and reissued by the platform
- One deployment serving several companies or departments
- No manual handling as volume rises
Accuracy built in
Every payment is matched back to the order that generated it.
- Automatic reconciliation to the originating order
- Sending the same order twice cannot create a second charge
- Reissuing a request cancels the one it replaces
We write the integration
We configure connections directly linked to your systems.
- CRM, billing platform, ERP or a scheduled export
- Integration written to your systems, not picked from a list
- Changes handled by the team that built it
Two charges come from us. The rest comes from your bank.
Here is what each line covers and how it is set.| Item | What it covers | How it is set |
|---|---|---|
| Platform | Hosted gateway, link delivery and automatic reconciliation | Monthly, by the payment methods you enable |
| Per payment collected | The Telecom Stack charge on each payment the gateway processes | A fixed amount per transaction |
| Setup | Integration, configuration and staff onboarding on the payment flow | Quoted after the needs analysis |
| Custom development | CRM or billing work beyond standard configuration, built by our specialists | Quoted after the needs analysis |
| Pay-by-phone | IVR collection flow on your number, where it is in scope | Quoted with the call flow |
| Card processing fees | Charged by your acquirer, direct to you | Per your merchant agreement |
Methods you can enable: credit and debit cards across Visa, Mastercard and the major schemes; Open Banking account-to-account; Google Pay; Apple Pay; PayPal; and pay by link issued over SMS, WhatsApp or email.
All prices exclude VAT. Rates are quoted following a review of your requirements, and your price is fixed in writing before you commit. Terms start at 30 days’ notice, not a fixed commitment.
Why there is no headline price here
The platform charge depends on which payment methods you switch on, and the per-payment charge depends on your volume. A single figure would be wrong for most readers. Tell us your monthly transaction count and average value and we will put a real number in front of you, in writing, before you commit to anything.
We never hold your money.
Funds move from your acquirer to your settlement account. Card processing fees are a matter between you and your bank, and we do not sit in the middle of them or mark them up.
An Irish business delivering higher order volumes with the payment work automated
The client, collecting deposits and balance payments on customer orders, was chasing those payments by phone. Credit control would reach a customer, the customer would agree to pay, and the agent then had to direct them to a link or to an invoice carrying a payment reference. At that point the call ended and the payment often did not happen. Card details taken instead were being handled by staff.
We deployed the payment gateway against their existing order data. A payment link is now issued per order and delivered by SMS, with card capture entirely on the processor-hosted page. Split payment was added so a single balance can be settled across more than one card. Payments reconcile back to the originating order automatically, and a link can be reissued and the old one cancelled when an amount changes.
Across ten months the system assisted the company in processing their orders.
Chasing invoices the same way? We will show you what it would take to change it.
Most of the wait is your acquirer, not our build
Which is why the first thing we ask you to do is request API credentials. Your dated plan is confirmed in writing at proposal stage, once we know which integration route applies.Needs analysis
We review how you invoice and collect today, which system holds your orders, and which integration route fits. A call and a checklist.
1–3 days from contactProposal and agreement
The solution, the commercials and what we need from you, in writing, with your dated delivery plan. You request API credentials from your acquirer.
From 2 daysBuild and prepare
Integration built against your system of record, message wording agreed, call flow built where pay-by-phone is in scope.
Confirmed at proposalTesting and sign-off
Tested against a sandbox or a test dataset, never against live customer debt, then walked through with you for sign-off.
Confirmed at proposalLaunch and monitor
Into production with us alongside you, then a period of light monitoring while we tune it.
Confirmed at proposalWhat sits underneath
The detail your IT or security people will want before signing this off.Card data never enters your estate. Capture happens on the processor’s hosted page. You do not store, process or transmit cardholder data electronically, which normally qualifies you for SAQ A under PCI DSS v4.0.1 rather than a full audit. We supply the processor’s current Attestation of Compliance on request.
SCA handled on the hosted page. Strong Customer Authentication is satisfied through EMV 3-D Secure 2, with low-value and transaction-risk-analysis exemptions applied at processor and issuer level. That covers Ireland and the EU under PSD2, and the United Kingdom under the Payment Services Regulations 2017.
Processor-agnostic architecture. The order and invoice model is independent of the card processor. Moving acquirer is a configuration and integration exercise, not a rebuild.
Multi-tenant by design. The platform partitions data and configuration per tenant, so one deployment can serve several companies or departments with records isolated between them.
How orders reach us. Either an API, where your system calls ours or exposes one we can call, or a scheduled feed: a structured file or message delivered on an agreed timetable in an agreed format. Both are supported, and which one suits is settled at the needs analysis.
Where the line sits. A spreadsheet somebody updates by hand is not an integration, and neither is a person reading figures off a screen. A spreadsheet exported to an agreed format on a schedule is, and we set that up with you. What the gateway cannot do is guess at unstructured data, or collect against an order no system has recorded.
Payments inside a phone call. Your phone system connects to the gateway over SIP at extension level, so payment can be collected on the call itself. An AI assistant or a dial-pad menu runs the collection, and the card is captured on the processor’s hosted page as it is anywhere else.
What you need at your end
A live merchant account with your chosen acquirer, API credentials issued against it, a system that can hand us an order by API or on a scheduled feed, and clean customer contact data. An internet connection, and nothing to install. The acquirer credentials are the item that most often holds a project up, so request them the day you decide.
What the payment gateway is not
It is not a billing or subscription-management platform. It collects against orders your own system generates, and it does not create them. It does not store card numbers. And while it is not tied to a single card processor or a single CRM, any one deployment is configured for the stack you choose.
Questions we are asked before signing
- Does this put us in PCI scope?
- It takes you out of most of it. Because card details are entered only on the processor’s hosted page, you do not store, process or transmit cardholder data electronically, which normally qualifies you for SAQ A — the simplest validation route — rather than a full audit. You still confirm your own site is not susceptible to script-based skimming.
- Are we locked into your payment processor?
- No, and that is deliberate. The gateway is built so the platform can be pointed at a different acquirer without re-architecting your business logic. Your acquiring relationship and your rates stay a matter between you and your bank.
- Where does the money actually go?
- Straight from your acquirer to your settlement account. Telecom Stack never holds your funds. We charge for the platform and per payment collected; card processing fees are charged by your acquirer, direct to you.
- Do I need to change my business systems?
- No. Your existing CRM or billing system remains the source of truth. It needs to be capable of providing the payment information the gateway requires, typically through an API or another supported integration method. The requirements datasheet sets out exactly what that means in practice.
- How fast do customers actually pay?
- Faster than a bank transfer, because there is nothing for them to do but tap. The link arrives on the phone they are already holding, opens a payment page, and takes a card, Apple Pay or Google Pay depending on what your acquirer has enabled. There is no login and no account to create.
- Can we take payment while we have the customer on the phone?
- Yes. Alongside pay-by-link there is a pay-by-phone flow: the customer rings a number, keys their payment reference, confirms the amount and enters their card on an automated line. Your agent never hears a card number. The flow is built and tested on Telecom Stack Cloud PBX; integrating a third-party phone system is scoped per deal.
- What if the amount changes after we have sent the link?
- You reissue it. The new link carries the corrected amount and the superseded one is cancelled, so a customer working from an old text cannot pay the wrong figure or pay twice.
- What do we need before you can start?
- A live merchant account, API credentials from your acquirer, a business system able to supply the payment information through a supported integration method, and clean customer contact data. Nothing to install at your end. The acquirer credentials are the item that most often holds a project up — request them the day you decide.
