Community hosted payment gateway


Everyone should have access

In order to have an alterative regarding the usability of payment gateways (like or other third party gateway), it should be well to have an open-sourced solution as basis for every developer. Also mostly to push user acceptance, this project must have to be a lever in the entrepreneurship people.

BTCz-pay - The open source project of the gateway is here:

Live API - (Beta version 0.1.1)

The gateway is an free to use API service that provide you end-to-end-user BTCz payment. It generating a new address (and QR) for each payment. It also provide you web UI for the payment process and states templates until success.

Use CoinMarketCap API

The CoinMarketCap API offer an interesting Hobbyist pricing that could allow 100’000 requests per month. So we could begin with 15 currency support, that the conversion rate will be refreshed all 8-10 minutes.

(The actual beta version give only a refresh all 55 minutes with 4 currencies; CHF, USD, EUR and BTC)

WooCommerce Plugin - (Beta version 0.1.0)

The WooCommerce-BTCz-gateway is an WordPress plugin that allow you to pay with BitcoinZ crypto-currency in your WooCommerce WordPress Online Shop. It use the gateway to provide payment templates.

Costs estimation (up to 500 users)


So, it’s about 500 BTCZ per month and per person in this forum (all count, but we also could be more than 500 user of the service). It’s very not an expensive project, it’s more time-consuming.


  • Hosted by the community, for the world.
  • Continuity in the service.
  • Could be financially autonomous.
  • A free for use test platform for developers.

Cubecart BTCz Payment Plugin
Woocommerce BTCZ Plugin, issues

Im not fully understanding what is it about. Is it a new type of plugin?
Is it a better solution? I guess yes but Im noob in codeing.
I appriciate your work anyways Marcelus!


:sweat_smile: Yep, I also read me again… and the explanation of what I would like to do is not clear. I will update the post.

… It’s about to create a other Payment Gateway like, but an fully open-source solution.


Can I say how much I love you Marcelus ?!?

You really rock man !!


yeah we need a source code or an replication of payment gateway…


:hourglass: Already 2 weeks, but here is a beta version of the BTCZ open-source payment gateway! :sunglasses:
I let you test it, with small amounts. Please note the invoice number in case of trouble.

  • There is no minimum limitation of the amount.
  • Use of BTCZ, USD, EUR and CHF currencies for the moment.
  • Currency are refreshed only once an hour (temporarily, then I plan every 12 minutes later).
  • The eCommerce plugins will comming soon…

Note: Use this topic if you have any issues or the github repository.


Nice alternative if we don’t hear from…


Wow! Amazing job Marcelus! Seems to be a better alternative, which we can improve and use for the others!


Yes, it’s a base of work for every developer (or coder) that would like us the BTCz as payment method. There is still a lot to do…

I also integrate a currency converter API get method:
that return a json like:
I’m checking to get up to 10 currency’s refreshed every 12 minutes (now it’s only 4 refreshed once per hour).

It’s will maybe help for the Fiat Converter project:


I hope @Akta86 returns back soon and continue.


So far I’ve created a payment gateway using the Gateway form on the main site. I think it works so far with only one thing:

The pingback didn’t seem to send any information - I had netcat listening on my pingback address and all I got was:

GET / HTTP/1.1
Connection: close

I haven’t tested the GET API yet, but the only thing that seems to be missing is a ‘success_url’ to send the payer back to the merchant site.


I just updated the code, pingback URL’s should now work. I manage the return URL as follow:

  • :srvPingback - Only executed on server side (never return back this value) once success.
  • :cliPingbackSuccess - Returned URL once success.
  • :cliPingbackError - Returned URL if fail (expired or error).


awesome I will test!


is there static ip of the server? so we can use it as extra protection for pingback check…
i will test it soon with my magento 2 btcz extension…


Yes there is a static IP (I send it to you in private).
@kovach, could you help with other plugins ?


@Marcelus yes I could, I just have to manage my very limited free time…
After magento we can check other plugins…


Nice to see you back here! :slight_smile:thank you very much for Magento Bro!
All of our devs hard work should be gifted!


Version 0.1.2 (beta) online


  • Almost instant payment checkout integration (5-8 sec)
    I use a temporary address, already having funds, to transfer the payment of the buyer to the seller’s wallet without waiting for confirmation of the blockchain. Limited to 100 BTCz.
  • Added payment amount in the QR code
  • Added unconfirmed amount in the invoice template
  • Added RUB and GBP currencies support
  • The currencies are now updated 2 time per hour (instead of 1 per hour)
    Since updated the free account to 333 calls per day, I’m also able to provide (in the actual demo) 2 more currencies and more rate refresh.
  • Show gateway usage statistics (total gateway, expired, paid)

Information about the instant checkout

The instant payment checkout is NOT without risks! In the case of a chain fork or any other transaction “rollback”, the buyer will lost the founds. We have also to think about this and other possible issues.

For the demo, I added a “Speed Pay Fee” of 5%. Again, this is only for test proposes and everyone can fork this project and change it to free (or more). I added this fee more to test possibilities to get a return of investment for a service. I will not get rich with this and I do not want to scam people.

I’m open for any discussion about how to improve this functionality :ok_hand:

Here a small demo on Youtube:
(I am not talented in video production, I do only a screen recording)

Need todo

  • [ ] Better explanation of the API usage
  • [ ] Youtube presentation (more professional than actual)
  • [ ] Test check list with 20-50 users and analyze the output logs
  • [ ] FAQ page
  • [ ] Buyer, Seller, Admin stats/login (with 2 factor Auth. by eMail, like
  • [ ] Other…

Stats at 13-OCT-2018 11:45


@Marcelus awesome work!

I got around to testing it again - it looks like ‘pingback’ url is actually ‘successURL’ which means that is the URL that its going to after the payment completes.

SuccessURL vs. Pingback

SuccessURL = redirect after payment completes

PingbackURL = IPN (instant payment notification) URL is the URL that the seller points to so they can update the details about their buyers balance/purchase. It should POST details like that ‘status’ etc.

I’ve not tested the GET API yet, but I’m about to test it now to see what the :cliPingbackSuccess and :cliPingbackError payload looks like.


Tx for feedback.
I will update the API documentation (with some example) in a couple of days.

To clarify a little the actual usage of the API, bellow some explication how I proceed it with the WP-Woocommerce Plugin.

To create a gateway

I make a request_payment/ GET call on the API as following:
(:parameters are the gateway info to use for personnalisation)

:srvPingback = The URL that the gateway GET once it’s paid with success (state 5).
In WP-Woocommerce, I manage it like $srvPingbackUrl = $order->get_checkout_order_received_url(); URL that contain the secret phrase like So that the order can be updated.

:cliPingbackSuccess and :cliPingbackError = URL for the client redirection on success (state 5) and on error/expired (state 2)

The ending 0 param is for spped checkout or standard (1=speed)

(The URL have to be encoded 2 time to awoid routing issue, I work on this)

It return a JSON string like that with the basic info about the gateway:


The important param is the “id”. You will need it for retrieving the gateway status. On this stage, all information like the asked amount, currency, exchange rate, the 3 URL, seller address, … , are stored in the database. a new payment address (with QR) is generated that can be retrieved by query of the “qr_simple” param :

At this stage, a invoice is generated that can be show on this URL (with the id after invoice/):

Fetching Data from Existing Gateway

I make a check_payment/ GET call on the API as following:

:id = The gateway “id” generated abow.


It return a JSON string like that with the status info about the gateway:

   "error":"gateway expired",

(in this example with an error: gateway expired)

You can GET this API URL (with the id) as many time as needed. in this case, the :srvPingback URL (with secret key) will never fire up. The :srvPingback URL only fire up on success (state 5). On success, this JSON string contain the "successURL":"https://mysite_or_IP/result/ param instead of err_callback_url param.

Important: The :srvPingback (set in the gateway creation) is never returned in any JSON string. It fire up a GET to the set URL only once the invoice is paid. I only tested it in WordPress with this plugin :

So, I hope it’s more clear :sweat_smile:

To answer you, @cryptorex, I don’t think it’s needed to “Pingback” any other information. Because we know all needed info by the check_payment/ call. And normally the online store, like in Woocommerce, all this info are already linked with the sercret key (Woocommerce_CheckOut_URL / ?WP_key=xyz123). Once this URL is fetched, it should update all the staff ?

But I can append some info after the :srvPingback URL like: &id=xxxx-xxxx-xxxxxx-xxxxxx&paid_amound=1234 … Is it really needed ?

Actually, the gateway send nothing back by expired gateway (excepting for client redirection).