A metered billing invoice fails differently from a flat one. A flat renewal carries the same amount every period, so your finance team knows the number before the charge goes out. A metered invoice carries a number nobody knew until the period closed. The compute, the API calls, and the seats are consumed first, priced second, and declined third. By the time the payment fails you have already delivered the month, and you are chasing money for work that is finished.

That gap gets wider when your customers sit outside your acquirer's footprint. EukaPay gives a Latin American SaaS operator a second route for exactly those invoices: a crypto or stablecoin payment against an invoice you raise, converted to fiat at a locked exchange rate and settled to your own business bank account. This guide covers what a metered billing system has to count, where the number goes wrong, and what to do with the invoices your card route keeps returning.

Metered billing charges a customer for what they consumed in a period instead of a fixed amount per period. The pricing lives on a unit: a gigabyte, a request, a minute, a document, a seat-day. The invoice is raised after the period closes, because until it closes there is no total.

That ordering is the whole difference. A flat subscription can be charged on the first of the month with no upstream dependency. A metered charge cannot exist until three things have happened in order, and each one is a place the number can move.

Metering means recording every billable event with a customer, a timestamp, a unit, and a quantity. Precision is a pricing decision, not an engineering one. Rounding a partial gigabyte up, counting a retried API call once or twice, and deciding whether a seat added on the 20th costs a full unit are all choices that change the invoice.

Rating applies your price book to the count: tiers, included allowances, minimum commitments, volume breaks, and currency. This is where most disputes start, because the customer agrees with the count and disagrees with the price applied to it.

The customer never sees your meter. They see a document with a total and a way to pay it. If the document does not show the units behind the total, the first response to a large month is a question instead of a payment.

Two reasons stack on each other, and neither is about your product.

The first is the amount itself. A metered total moves period to period, sometimes by a lot. A charge that does not resemble what an issuer last approved for that merchant can be treated as a riskier authorization than a predictable one. You cannot fix that by writing better invoice copy.

The second is distance. Every customer outside your acquirer's footprint adds another issuer, another set of rules your acquirer did not write, and another approval path you have no visibility into. When a Latin American operator sells across the region and into North America and Europe, the card route is being asked to work across issuers that behave differently from each other.

Together they make the invoice your team knows well: a legitimate customer, a correct number, and a cross-border decline nobody can explain from the response code alone. A variable amount is also a weaker candidate for a second attempt than a flat one, because the amount that failed is not the amount that will be presented next time.

Undercounting is a silent revenue leak and overcounting is a support ticket, so most teams tune the meter hard. The two steps after it usually get less attention.

At the meter,

events dropped during a deploy, counted twice when a request is sent again, or attributed to the wrong customer never reconcile later. The invoice will be internally consistent and still wrong.

At the invoice,

a total with no unit breakdown invites a hold. A currency the customer does not think in invites a conversion argument. A document that arrives late in their approval window invites a payment in the following month.

At the payment,

the step most billing stacks treat as someone else's problem is the one that decides whether the period turns into cash. A correct invoice that cannot be paid on the route you offered is worth the same as an incorrect one until it clears.

EukaPay is the route to reach for on the invoices your card processor keeps returning. Your meter, your rating logic, and your collections process stay exactly where they are. EukaPay gives the finished invoice a second way to get paid, and it puts the resulting funds in the same bank account as everything else.

Your system stays the source of truth for the count and the total. EukaPay handles the part after the total is set. You create an invoice in the merchant dashboard or through the API and send it for that period's total. Your customer can pay it in most major cryptocurrencies like BTC, ETH, LTC, SOL, USDC, USDT. Where a customer bills on a fixed schedule instead of on usage, EukaPay subscriptions send invoices on a recurring schedule at intervals from daily to annually, and that is the whole of that feature.

One platform sits under both: instant crypto-to-fiat conversion at a locked exchange rate to remove your exposure to crypto price swings, support for most major cryptocurrencies, and settlement in USD, EUR, GBP, and CAD to your bank account. The locked rate is applied by default on every conversion, on pay-ins and on payouts, so the fiat value of a metered invoice is fixed at the moment your customer pays it. A crypto payment confirms on-chain, so protection against chargebacks is a property of the payment method.

The documented API surface covers invoices, subscriptions, payouts, balance transfer, and customers. That is enough for your billing job to raise each invoice at period close without anyone opening a dashboard. For a metered book of business spread across several markets, it is the piece worth adding first.

Create a EukaPay account

, complete verification, provide your legal business information, and generate an API key. The

EukaPay API documentation

covers the invoice, subscription, and customer endpoints your billing job will call at period close.

What is metered billing?

Metered billing charges a customer for the units they consumed in a period instead of a fixed amount per period. The invoice can only be raised after the period closes, because the total does not exist until then.

Does EukaPay calculate usage for a metered invoice?

No. Your own metering and rating produce the amount. EukaPay creates and sends the invoice for that amount, and handles the payment and the conversion.

Can EukaPay send invoices on a recurring schedule?

Yes. EukaPay subscriptions send invoices on a recurring schedule at intervals from daily to annually. Metered billing works differently, because each period's total comes out of your own metering.

Which cryptocurrencies can a customer use to pay a metered invoice?

EukaPay supports most major cryptocurrencies like BTC, ETH, LTC, SOL, USDC, USDT on the pay-in side, so your customer can settle an invoice in the asset they already hold.

What currencies does EukaPay settle to my bank account in?

Settlement currencies include USD, EUR, GBP, and CAD, paid to your own business bank account. You can also choose to keep the funds in crypto instead.

Does a stablecoin payment on a metered invoice carry chargeback risk?

A crypto payment confirms on-chain, so protection against chargebacks is a property of the payment method, not something layered on top of it.

Can I create metered invoices through the EukaPay API?

Yes. The documented API covers invoices, subscriptions, payouts, balance transfer, and customers, so a billing job can raise each period's invoice without a manual step.

Do I have to move off cards to add this route?

No. Most operators keep the card route for the customers it serves well, and use a EukaPay invoice for the cross-border customers it does not.