Most people land here with one of three problems
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 timeFrom “due” to “paid”
Five stages. Your customer only ever sees one clean link — no internal identifiers, no account exposure, and no card form for your staff to handle.| 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 |
| Link issued | A secure payment page for that one order | The card processor |
| Link delivered | A short tap-to-pay link, by SMS or by email | 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 card details your staff never see.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.
Higher volume, no extra handling
Handle higher volumes without adding manual work. One processing layer can serve several companies, departments or downstream clients from a single deployment.
Nobody reconciles anything by hand
Payments are matched back to the originating order automatically, re-sending an order cannot create a second charge, and reissuing a payment request cancels the one it replaces.
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.
Card data never reaches your estate
Card capture happens on the processor’s hosted page, so cardholder data never enters your estate, and Strong Customer Authentication is satisfied there across Ireland, the EU and the UK.
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.
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 is 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
One deployment can serve several companies or departments, so it suits a single business and a partner running many clients.
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
Where the connection to your systems does not exist yet, we write it.
- 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.
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.
