Why Communications Platforms Take Crypto for Prepaid Balances

A sales team is thirty minutes into an outbound campaign when the dialer stops. The balance hit zero. The card meant to top it up was declined an hour earlier and nobody noticed, because a failed top-up does not make a sound.

It is worth being precise about that failure, because it is not the same one as a lost checkout.

Support inbox full of customers asking for one address they can keep? Give them one that stays theirs.

A top-up is not a purchase

A one-off purchase is a decision. Someone considers it, compares, buys, and pays attention while it happens. A prepaid top-up is the opposite of all of that. Same customer, similar amount, many times a month, and never the point of anyone’s day.

The economics follow. A 20 EUR top-up cannot absorb a support ticket or a five-minute detour. And when it fails it does not cost you a sale, it stops a service that was already running, which the customer feels immediately and remembers longer.

Ad networks hit the same wall with advertiser deposits, and the resemblance is not a coincidence. Small, frequent, credit-based funding of a live service behaves the same way whether the service is calling minutes or ad impressions.

Why card top-ups fail more in this customer base

Cards were designed for a person buying a thing. A repeated small international charge against a prepaid card is not that.

• Risk models dislike the pattern. Small, frequent, cross-border charges resemble card testing from the issuer’s side, and issuers err towards declining.
• The cards themselves are thinner. Prepaid and virtual cards are common here, and they carry lower limits and worse international acceptance.
• Geography works against you. Communications platforms sell into markets where card penetration is lower, so the customers who need the service most often have the cards that work least.
• Authentication lands at the worst moment. A 3DS challenge in the middle of a shift turns an urgent top-up into a support ticket rather than a retry.

Any one of those is survivable. Together they produce a decline rate on top-ups that looks nothing like the decline rate on a first purchase, and the revenue cost of payment declines is one of the least examined lines in a prepaid business.

Worth saying plainly: crypto does not fix a customer who has no money. It fixes the customer who has money and cannot get it to you. In this vertical, that is most of the problem.

The invoice-per-top-up trap

Most crypto integrations copy the card flow. The customer clicks top up, the system generates an invoice, an address appears, the customer sends, the balance credits. Next week it starts again with a new address.

Fine at twenty top-ups a month. At two thousand it produces one specific problem, and it is structural rather than accidental. The payment address on a checkout order is single use. Every order gets a fresh one, and funds sent to an address from an older order are not linked to the order they used to belong to.

Which is exactly what a busy customer does, because they saved the address the first time and it worked. So the support inbox fills with the same three messages. I sent to the address you gave me. My balance did not update. Can I just have one permanent address.

One thing not to tell your team while you are fixing this: that an expired order is a dead one. It is not. A late payment can still be settled to you, for a window you configure yourself, per merchant tool. We go through that and the rest of the drop-off points in why crypto checkouts do not convert. The address is the part that is genuinely single use, and it is the part your customers will trip over.

One address per customer, permanently

The answer to that last question is yes, and it is what payment channels exist for.

Each customer gets a dedicated address that stays theirs. They save it once and send whenever the balance needs topping up, without asking your system for permission first. Your side detects the incoming transfer, attributes it and credits the balance.

The reconciliation question changes shape too. It stops being which invoice does this payment belong to and becomes which customer owns this address. You know that answer because you assigned it, and the attribution comes back to you against the contact rather than the address, matched on the identifier you already use for that customer in your own system. A callback fires on the channel when the money lands, which is what your crediting logic should hang off.

Two details worth knowing before you design around it. A channel holds one customer and one purpose, so a customer who deposits for two different reasons needs two channels. And one channel can carry several addresses, because the chains that share an address format share one while standalone chains each get their own. We have written up how to create a payment channel for the dashboard route, and there is a quickstart for the payment channels API for wiring it into a billing system.

Auto-reload, and the part nobody mentions

Here I have to be blunt about a limitation.

Recurring crypto payments exist, and we support them. What does not exist is the pull. Card auto-reload works because the card is on file and the merchant can take funds. There is no equivalent here. No stored payment method, no automatic debit, nobody reaching into a customer’s wallet when their balance drops below a threshold. Recurring means the request repeats, not the charge.

Our own recurring billing has exactly that shape, and we say so on the product. It generates an invoice on a schedule, weekly or monthly, and emails it. Each invoice still has to be paid by the customer. Cancelling stops future invoices and nothing else.

What you can build is the half that works, and it covers most of the value:

• An alert that arrives before zero, not at zero. The whole failure mode above is a balance running out unnoticed. This one is yours to build, on your own balance data. We do not ship a low-balance alert.
• A saved address the customer can push to in seconds, from a wallet they already have open.
• Automatic crediting on arrival, so the customer’s only job is sending.

One detail worth stealing. Set the alert threshold in minutes of service remaining, not in currency. Your balance is below 15 EUR means nothing to somebody mid-shift. About two hours of calling left at your current rate produces a top-up.

What the finance side looks like

On the Standard plan our pricing page publishes, incoming payments cost 1% per transaction, with no monthly fees and no setup or integration fees. Enterprise pricing is custom and volume-based, so if you are running the kind of volume this post describes, the number is a conversation rather than a table.

If you would rather not hold the asset, payments convert automatically at the rate locked when the customer pays, and you settle in euros. Two things to get right there. The exchange rate is fixed at payment, so the amount you were quoted is the amount you receive. And the settlement currency is not a field you can safely ignore, because leaving it alone does not preserve a choice. Do nothing and you settle in USDC. The currency an order actually settles in comes from the integration it was created through, not from an account-wide default, so a platform that wants euros needs to set it on the API key doing the work.

Then there is the word settlement itself, which in this industry gets used for two different clocks. Settlement is the moment a payment becomes final and lands in your CoinGate balance. It is not the moment money reaches your bank. That second movement is the withdrawal, and our pricing page lists automatic settlements as Weekly on Standard and Weekly / on-request on Enterprise, with the Enterprise card offering on-demand automatic settlements and the FAQ saying faster or customised payout schedules can be arranged for Enterprise clients on request. If your cash cycle needs something faster than weekly, that belongs in the plan conversation rather than the integration one. We separate the three terms properly in settlement vs payout vs withdrawal.

There is one structural advantage that matters more here than almost anywhere else. A crypto payment is push-only, so the payer cannot reverse it after the fact. On a consumed prepaid balance that is not a small thing, because calling minutes that have already been used are not recoverable and a chargeback on them is a straight loss. Refunds remain available and remain your decision, which is a different thing entirely from a customer’s bank taking the money back six weeks later.

What MoreMins and Squaretalk show

Two of our own case studies sit either side of this vertical, and they were written for different reasons.

MoreMins: the operator case

MoreMins is the closest thing in our estate to a straight telecom answer. A UK-based global mobile virtual network operator, founded in 2015, selling eSIM data plans, international calls and local and international numbers through an app rather than a SIM card. Crypto now accounts for over 10% of their total payments, and the volume has been doubling each year.

Their reason for adopting it was not decline rates. It was privacy. Starting to accept cryptocurrency payments for our privacy-oriented services was the logical next step, their founder and CEO Andrius Butvilas said, and the point was letting customers buy telecommunications services with more anonymity. Which is worth noting rather than glossing over, because it is a second, independent reason crypto lands well in this vertical, and it has nothing to do with the payment plumbing. They also make refunds in crypto, which is the practical version of the point above about refunds staying your choice.

Squaretalk: the compliance case

Squaretalk is a unified communications-as-a-service solution operating in over 150 countries, with a client base that leans heavily fintech and international. We do not publish their transaction figures, and the useful part of their story was never a number anyway.

Their Founder and CEO, Elie Rubin, put the motivation plainly: “We didn’t adopt crypto to be trendy. We did it to solve real-world payment friction. For our clients, it’s about flexibility, convenience, and speed.”

Three things in that case study generalise well to any communications platform:

• Compliance came before the technology. Their leadership treated a provider’s KYC and AML posture as the selection criterion, not the feature list.
• No volatility exposure by design. Payments convert to euros on receipt, which is the same thing we would recommend to any platform holding customer balances.
• The chargeback problem went away, and settlement got faster specifically for clients in regions where banking is slow. That geographic overlap is the whole point.

His advice to other software companies was to make crypto just one part of a multi-channel payment strategy rather than a replacement for banking. Correct frame here too.

Where this does not fit

• Postpaid enterprise contracts. A monthly invoice to a large account is an invoicing problem, not a top-up problem, and it has a different answer.
• Customers who will not touch crypto. This is an additional channel. Building as if it replaces cards will cost you more than the declines did.
• Very small top-ups on expensive networks. If the network fee is a meaningful share of a 3 EUR top-up, the experience is bad no matter how good the integration is. Network choice carries most of the weight here.
• Any flow that needs credit before confirmation. Confirmation is fast but not instant, and it varies by network. You have to set your own crediting policy and be honest about it.

Frequently asked questions

Does a customer need an account with us to top up in crypto?

No. They send from a wallet they already control to the address you gave them. With a payment channel that address is permanently assigned to them, so after the first time there is nothing to request, generate or wait for.

Can we charge a customer’s wallet automatically when their balance runs low?

No, and it is worth settling that before it becomes a roadmap item. Crypto has no stored payment method and no pull mechanism, so recurring crypto payments repeat the request rather than the charge. A threshold alert plus a permanent address gets you most of the outcome without pretending the mechanism exists.

Which assets make sense for top-ups?

Stablecoins carry most of the weight, since a customer funding a service balance does not want the amount moving between sending and crediting. We support USDC and EURC, and for payment channels specifically the network spread is the thing to look at. USDC can be assigned on Ethereum, BNB Smart Chain, Solana, Polygon, Base and Optimism, while EURC is Ethereum only. If your typical top-up is small, that difference decides the experience.

Do we have to hold crypto if we accept it?

No. Payments can convert on receipt and settle to you in euros, which is what we would recommend for any business holding customer balances. Holding crypto is a treasury decision and belongs apart from the decision to accept. Just set the settlement currency deliberately, because the default is USDC.

How is a payment channel different from a normal crypto checkout?

A checkout order is created per payment, its payment address is single use, and the shopper has a fixed window to pay. A payment channel is a persistent address assigned to one customer, so attribution happens against that customer rather than against an invoice, and they can send at any time.

The bottom line

Prepaid top-ups are a payments problem wearing a billing problem’s clothes. Small, frequent, urgent, and concentrated among customers whose cards fail most, and every one of those makes the card rail a worse fit than a dashboard average suggests.

Crypto fits the pattern because it removes the parts that break: the issuer decision, the reversal, the cross-border delay. It does not remove the need for a permanent address, an alert before zero, and a customer willing to use it. And it will never auto-charge anyone.

If your support queue is full of people asking for one address they can keep, give them a payment channel and let them keep it. Look at what payment channels give each of your customers, and if you are not with us yet, start here.