CoinGate

There is somebody at your company who converts the crypto balance into euro. Usually by hand, usually late in the week, at whatever rate happens to be showing when they get round to it.

That job can run itself. And the reason it is worth doing properly rather than quickly is the rate.

A conversion happens in two steps instead of one. The first locks a price. The second executes it. Nothing can move between the moment you decide and the moment it happens, which is the entire point of splitting it in two, and it is why the number in your records matches the number you agreed to.

The locked price does not last long though. About a minute in our own example, and it is not a fixed figure, so anything automating this has to read the expiry we hand back rather than assume sixty seconds.

The pattern itself is one sentence. Keep the coins as they arrive, then let a scheduled job read each balance, price the conversion and confirm it before the quote expires. Nobody has to sit down on a Friday afternoon and decide whether a rate looks acceptable.

The full flow, with a working example, is in the first comment.

Hosting has one of the most crypto-comfortable customer bases in B2B and a renewal cycle that crypto handles badly. Both are true. Only the second one is fixable.

Start with what cards do wrong here. An issuer looks at a recurring cross-border charge for a small amount and declines it, quietly. The customer never learns their renewal failed until something stops working. Crypto turns that silent decline into a visible unpaid invoice, which is a problem somebody can actually act on.

However, there is no getting around the mechanics. A blockchain payment is pushed by the holder of the funds, so there is nothing on your side to debit. Our WHMCS module has no auto-charge function at all, which means this is not a setting somebody forgot to switch on. It cannot do it.

So the renewal email stops being a notification and becomes a payment step. That is the whole integration, really. Everything else is detail.

The details still matter though. At checkout there are two clocks, two hours to pick a coin and network and 20 minutes to send. Underpayment tolerance is configurable from 0% to 10% per product. Payment addresses are never reused, so a customer paying yesterday's address gets no credit, and a forgotten renewal invoice is exactly the situation that invites it. Business verification usually takes one to two business days.

On whether the audience is really there, MVPS.net, a European VPS provider, put it plainly in their case study. 24% of their customers now pay through CoinGate, and their bank does not complain about the transactions coming from it.

One honest boundary. This fixes churn caused by cards failing. It does nothing at all for a customer who no longer needs the server.

Thinking it's time to give your renewal invoices a second way to get paid? Start with us.

Full guide in the first comment, including the WHMCS install and how settlement fees behave on five euro invoices.

Ask what happens on renewal day and you get two very different answers depending on whether you take cards or crypto.

With cards, nothing happens. That is the appeal. The charge goes out on its own and nobody has to be involved.

With crypto there is nothing to charge. A blockchain payment is pushed by the person holding the money, so every renewal needs your customer to sign it themselves. There is no card on file to fall back on.

What can be automated is the other half, which is producing and sending the invoice on the right day, every time, without anybody remembering to. That is the part worth building, and it runs on our side rather than yours. A daily job reads every active schedule, creates the invoice and emails your customer a link to pay it. You do not run anything. We send the email.

Two limits to know before you plan around it.

Schedules are weekly or monthly only. There is no annual option, which rules out a lot of yearly plans until that changes.

The billing day is anchored to the date you start on. Not the day you created the schedule, and not the first of the month. Every invoice after the first one lands on that same day, so pick it deliberately instead of letting it default to whenever you happened to set things up.

There is also a tolerance setting worth turning on, because a customer's wallet fee can eat into the amount that lands. A payment arriving slightly short still counts as paid, up to a percentage you choose.

And one boundary that stays yours. Cancelling a schedule stops future invoices and leaves already-issued ones alone, so chasing those is still your job.

The full build, from customer record to confirmation, is in the first comment.

400 paid orders. 24,000 EUR through checkout. Total cost for the month, 245.42 EUR.

That is 1.02% of gross on a 1% plan, and the two hundredths are the interesting part, because gateway cost is never one number. It lands at five separate events.

Processing took 240.00 EUR at 1% of the order value. Worth reading that base twice: the percentage is calculated on the order amount you set, not on whatever arrives afterwards.

Conversion cost nothing, and this is the line most people get backwards. Automatic conversion at checkout is excluded from our 1% exchange fee. Manual conversion on the platform is the one that costs 1%. Automating it is the cheap path, not the premium one.

Withdrawal cost nothing either, because the money went out over SEPA. SWIFT is 0.50% with a 50 EUR minimum fee, so anything under roughly 10,000 EUR pays that 50 either way.

Two refunds came to 0.62 EUR at 0.25 EUR plus 0.1% each. That 0.1% only applies when the currency being refunded differs from the currency the refund is issued in, so a same-currency refund is just the 25 cents.

And the line nobody budgets for. Eight orders arrived about 1% short, and Underpaid Cover absorbed 4.80 EUR of that rather than leaving eight customers with unpaid invoices. It is a real cost, and it is cheaper than eight support tickets.

One condition on that last one, because it is easy to miss. A short payment is only marked paid automatically if it also arrives inside the payment window. Short and late is not covered.

For context on which of these lines most merchants actually touch, our H1 2026 report has 75.4% of orders settling to fiat and EUR leading settlements at 66.2%. Most of our merchants are on the free SEPA path.

The full breakdown is in the first comment, with the worked month and the nine questions a fee table cannot answer.

Your crypto checkout runs on two clocks, and most teams have never looked at either one.

The first gives a shopper two hours to pick a coin and a network. The moment they pick, the second one starts and they have 20 minutes to actually send the money. Neither is a parameter you pass when you create the order, so whatever else you tune, your funnel inherits those two numbers.

Once you know that, most of the mystery around crypto checkout conversion goes away. It behaves like any other funnel problem. It just has its own specific failure modes, and hardly anyone measures it that way.

Take underpayments. Some wallets take the network fee out of the amount your customer typed rather than adding it on top, so the order arrives slightly short through nobody's fault. We can absorb up to 10% of a shortfall automatically, set per product. However it only works if the money arrived inside those 20 minutes. Short and late is a different case.

Then there is the form. A first-time shopper has to give an email, a name, a date of birth and a country of residence, because the law requires it, and it lands after they have already decided to buy with a clock running. You can send those details along when the order is created and they arrive pre-filled. That is the cheapest conversion fix on the list.

Two more for whoever maintains the integration. An expired order is not necessarily a lost one, because a late payment can still settle inside a window you configure. And underpayment is not one of the nine order states, so anything watching only the state will miss it entirely.

The full list of failure modes, and what to do about each one, is in the first comment.

"Fastest prop firm payouts."
"Prop firm payout proof."

Those are real search phrases, typed month after month by real traders. Which tells you where trust in this industry actually gets decided, and it is not on the marketing page.

The payout is the one moment a firm has to prove it is real. So it is worth understanding what happens between pressing send and a trader seeing their money.

A batch goes in as a spreadsheet, capped at 300 rows, or through the API. It sits as a draft, and an unconfirmed draft expires in five minutes. After confirmation, screening runs on the recipient and on the destination wallet, then the payment goes out.

Three details that catch teams out.

Roles decide who can send. Owner and Administrator can execute payouts, Accountant and Support can only view them, and the developer who built your integration has no access to payouts at all.

Four-eye approval means whoever creates a batch cannot approve their own batch. Funds are held while the approval is pending, and a rejection releases the hold back to your balance.

Identical rows are removed inside a batch. That protects you from a copy-paste accident, however it also means a genuine duplicate payment gets dropped, so give every row its own reference.
On cost, a payout on our Standard plan is 0.50 EUR plus 0.5%, or 0.50 EUR plus 1.5% if we convert at the moment of sending.

And the honest part. A wrong address in a row is a wrong payment, because an on-chain send cannot be recalled the way a wire sometimes can. Paying third parties is also enabled per account after we look at what you are paying for and where, so it is not switched on by default.

The customer paid. Your system still thinks they did not.

That gap is one of the most common support tickets in any payment integration, and most of the time nothing is actually broken. The confirmation is still trying to reach you.

Delivery retries on a published schedule, up to 40 attempts, and the gaps widen as it goes. The first five come a minute apart. The last five are a day apart. So a confirmation can land days after the money did, and silence in the first hour proves nothing.

When it truly will not arrive, there are five conditions where we stop trying immediately instead of retrying. Two of them are worth knowing even if you never touch the code. A redirect on the address we send to, and any kind of login wall in front of it. Putting a password there does not harden that endpoint. It switches it off.

Everything else is answerable in two questions, and the API answers both. Did we attempt delivery for this order, and what did your own server say each time we tried? The second one usually ends the argument about whose side the problem is on.

One more thing worth checking before anyone opens a ticket. If no notification address was ever configured on the order, nothing was attempted at all, and that shows up as its own separate state rather than as a failure.

The full guide, with the retry schedule and the diagnostics, is below.

coingate.com

Accepting crypto does not make a sale tax free. The crypto did not make the sale tax free, it just settled the bill.

This confusion has a real origin, and it is a court decision that gets quoted half way. In Skatteverket v Hedqvist, Case C-264/14, decided 22 October 2015, the Court of Justice of the EU held that exchanging Bitcoin for fiat is a supply of services for consideration under Article 2(1)(c) of the VAT Directive, and exempt under Article 135(1)(e). The exemption covers the exchange transaction. It has never covered what you sold.

Sell a laptop for 1,000 euro and take payment in crypto, and you owe VAT on 1,000 euro.
Which leaves the practical question of which value goes on the invoice.

Article 91(2) of the VAT Directive, applied by analogy, points to the most recent selling rate on the representative exchange market at the moment VAT becomes chargeable, or the latest rate published by the European Central Bank. Germany's Federal Ministry of Finance, in its letter of 27 February 2018, treats Bitcoin used as a direct contractual means of payment the same as conventional means of payment, and accepts the last published selling rate from a conversion portal when it is documented. Irish Revenue follows the same spine, with the taxable amount set at the euro value at the time of supply and no change to how taxable profits are calculated. Accounts for tax purposes cannot be prepared in crypto at all.

Different countries, same spine. Crypto is the payment rail, and the tax follows the transaction.

Two things are worth acting on this year.

One crypto payment can contain two taxable moments. Income at receipt, and then a separate gain or loss if the value moves before you convert. Converting to fiat on receipt removes the second one entirely, which is the quietest argument for fiat settlement anyone has made.

And DAC8, Council Directive (EU) 2023/2226, applies from 1 January 2026. First reports cover the 2026 year, land with tax authorities in 2027, and get exchanged between member states by 30 September 2027. The obligation sits on providers rather than on merchants, which is precisely what makes your provider's compliance your problem.

Five records make all of this survivable: the date, the crypto amount and asset, the fiat equivalent value, the exchange rate used together with its source, and the wallet addresses and transaction IDs.

This is general information rather than tax advice. Crypto tax treatment still differs across all 27 member states, so which rate source your authority accepts is a question for your advisor rather than for a blog.

hashtag hashtag hashtag

Crypto reconciliation gets easy or hard based on decisions you make before a single payment arrives.

Done badly, month-end turns into a person squinting at a block explorer next to a spreadsheet. Done well, it is a scheduled job nobody talks about.
Four things create the mess, and the first one is worth more than the other three combined.

Attribution. Ten customers paying into one shared address gives you ten deposits and no way to tell which is which. It links unrelated payments together and forces you to untangle them after the fact. Fix it at the address level with a dedicated address per customer or per invoice, and half of reconciliation disappears before it starts.

Then under and overpayments, where the amount received does not match the amount invoiced. Then network fees, because unreconciled gas is one of the most common reasons crypto books do not balance. And finally multiple networks, since the same stablecoin can arrive on Ethereum, Base, Solana or Polygon and your ledger needs to know which one it came in on.

There is an accounting layer underneath all of it. The IFRS Interpretations Committee concluded in 2019 that cryptocurrencies are neither cash nor financial assets, which generally lands them under IAS 38 as intangible assets, or IAS 2 as inventory if held for sale. The practical consequence is that receiving crypto and later converting it are two separate events, and a conversion at a different price is a disposal you have to record. Settling straight to fiat removes that second event.

Two engineering rules make the remainder boring. Make your callback handler idempotent, because a webhook can fire more than once and receiving paid twice should never create two ledger entries. And verify before you act, by calling the order details endpoint instead of trusting the payload in front of you.

A healthy setup ends up with a dedicated address per customer or invoice, callbacks feeding the accounting system, a fiat value and an order ID on every transaction, and gas accounted for as a cost rather than a rounding difference. Set that up once and month-end stops being an archaeology project.

Thinking it's time to make your crypto books tie out on their own? Start with us.

hashtag hashtag hashtag

The full guide: https://coingate.com/blog/post/crypto-payment-reconciliation

Day 28, the invoice is approved. Day 29, the bank sends the wire. Day 34, your supplier emails asking where the money is.

Most of the pain in payables was never the payment. It was not knowing.
A stablecoin transfer fixes that one leg and leaves everything else standing. The purchase order stays. The invoice stays. The approval workflow and the three way match stay exactly where they were. Net-30 is a contract term, not a property of the rail. What you gain is a settlement you can watch, with an amount, an asset, a network, a fee, a timestamp and a transaction hash attached. What you lose is the ability to blame the bank.

Two things tend to surprise people.

First, USDC on its own is not a payment instruction. USDC on Base is. The network belongs in your vendor master file right next to the address, the way IBAN and BIC are recorded together. We support USDC on seven networks and EURC on Ethereum only, so that field carries real consequences.

Second, the FX exposure does not disappear, it moves onto your books.

Paying a dollar invoice out of a euro balance means somebody carries the conversion. Our payout pricing is 0.50 EUR plus 0.5%, rising to 0.50 EUR plus 1.5% when we convert at the moment of payment, with the network fee on top. That percentage point is the price of not holding dollars.

Now the honest part, because this is a poor fit in more cases than a vendor usually mentions. A domestic SEPA supplier already receives a euro credit transfer that is same day and effectively free. Anything that depends on reversibility does not belong on a rail where payments are final. One large annual payment to a single strategic supplier is not worth the change either, because the operational saving is noise and the relationship risk is not.
And the real blocker is rarely technical. No integration routes around a no from somebody else's finance department.

One fraud note for your AP team. A wallet address arriving by email is exactly as trustworthy as bank details arriving by email. Call the vendor on the number you already had.