Bancontact payment method

As discussed at the gathering: Global Gathering - Day 8 - Pipe Prioritisation - DEV PIPE

We agree to do a spike on how much it would take to provide Bancontact as a payment method.

Bancontact (ex Mister Cash) is the leading payment method used in Belgium / Netherlands / Luxembourg (Benelux).

The goals of the spike were:

  1. know the best way to integrate bancontact : through stripe https://stripe.com/docs/sources/bancontact or in another form
  2. Estimate the size of the work to be done and the main steps and their complexity

The scope of this spike excludes Subscription / recurring payment.

To get bancontact to process recurrent payments without authorization through Stripe is another story that is possible and supported but will require some work on the stripe integration at least: https://stripe.com/docs/sources/bancontact/recurring

@luisramos0 did the spike and @maikel reviewed it here:https://github.com/openfoodfoundation/openfoodnetwork/issues/3901

The following of this post is mostly a copy-paste of the content in Github so that we can pursue the discussion here. Luis, Maikel, if I changed anything from what you did, please tell me so.

How Bancontact works

  1. Bancontact does not have an open API that we can use directly. Every business has to go through one of their partners to actually handle payments. That could be Mollie, Stripe or some other listed partner: https://www.bancontact.com/en/professional/payment-button
  2. Customers want to pay with the Bancontact app instead of a credit card. While Stripe and Paypal both take credit card payments and a business can choose with which payment provider they want to accept cards, Bancontact is a different way of paying. The idea was that a customer connects their bank account to Bancontact and can then make easy transfers through a smartphone app.
  3. Bancontact is more similar to a type of credit card than a type of payment gateway. We now have to find the best payment service provider accepting Bancontact payments.

Payment authorization with Redirect

In this payment method, Bancontact, we need to redirect the user to an external website that will then redirect back to OFN.
This payment workflow will require some rework of the stripe gateway (maybe we create a separate stripe gateway for this type of integration).

An important point apart from implementing the redirect logic is that this will require us to have some sort of webhooks that receive info from stripe when the payment is authorized: the user is redirected to the payment website and then back to OFN but the authorization in the payment system is asyncronous and OFN will need a webhook to receive a call from the payment system, after the user is redirected back, stating whether the payment was authorized or not.
This will require some work to create the webhook.

Stripe sources or other payment gateways?

To get this integration working with Stripe we would need:

  • find out how to configure stripe for this
  • create payment method and it’s custom details in the backoffice
  • develop code to call stripe with appropriate details (source)
  • develop webhook to take response from stripe
  • developer code to wait for webhook call, validate and show user appropriate feedback

Overall, this looks like a straight forward problem but there are quite a few things to do and test.

The work done to make this work with Stripe will be reusable for other payment methods. Of course stripe fees will be an important point (see below).
This redirect logic might also be useful for PSD2 #3927

Apart from Stripe, there are many other payment gateways that integrate with bancontact.
One of the providers is a Belgium provider https://www.mollie.com/en/pricing/ that integrates with bancontact and has a spree plugin that works with Spree v3.

Fees

Lets look at some example data. A wholesaler may have 120 orders per month with an average order of €100. A food hub may have 200 orders per month with an average order of €30.

Provider Fee hub fees wholesaler fees
Stripe 1.4% + €0.25 €134 €198
Mollie €0.39 €78 €47

Well, looking at the numbers mathematically, Stripe is only cheaper if the average order is less than €10. That’s very rare. In Australia, many food hubs would say that they can’t afford Stripe. Is that the same in Belgium? No separate pricing about Bancontact via Stripe was found.

Robust implementation and maintainability

Stripe is very capable of implementing robust solutions. Mollie may not have the same standard of service but all payment providers are pretty good. The Spree payment gateway looks okay. It has recent commits. Both seem to have an easy API.

Conclusion

Integrating a new payment gateway into OFN is a long-term investment. Main criteria are fees for the enterprise and maintainability.

Stripe Mollie
Pros Quicker to implement Cheaper + We would win access to a new provider as alternative to Stripe and Paypal. That reduces dependency.
Cons Dependency and price Mollie will not have the same service/docs/etc of Stripe Implementing bancontact with mollie will take longer than doing it with Stripe because it will be a new gateway that will require setup (that will mostly be already done in Stripe)

Maybe we want both? First implement Stripe to have a quick solution and then make it great by implementing Mollie or similar?

Estimated amount of time to implement through Stripe

List of tasks above, webhook and validation part being the most novel thing to do. Luis estimate is L, guessing that a dev would take at least 40 hours to do this.

Remaining questions for the community

Is there another payment gateway like stripe that we would like to integrate with?

Were there any plans to integrate with another gateway in the past? This could be a good opportunity to build that integration as long as that new payment gateway integrates with bancontact.

What should be our next steps?

ping @Theodore @Kirsten @danielle @MyriamBoure @sauloperez @lin_d_hop @Matt-Yorkley @nick

EDIT FROM @Rachel: after a quick chat we Théo on Slack we agree that I would edit this post to remove email credentials (as this post is public).

Basically this was a forwarded email exchange between Renata (Payconiq) and Bertrand (Les paniers Lorrains ?)

@Theodore I’m not sure I understood exactly the email between Payconiq and Bertrand. How did the conversation started? Is payconiq widly used in Belgium? Is this something we need to study as well?

For everyone, payconiq website:

Excuse me if I’m being stupid - but I thought that the main reason there was pressure for additional payment gateways and methods was because Stripe is considered too expensive? So doing this through Stripe wouldn’t solve the problem? Or Belgium / Bancontact is a different case?

Very detailed report! I have to admit that that Mollie service looks very interesting and affordable. I think I get it but I’d like to understand what are the differences compared to Stripe.

For bertrand the digital paiement method are expensive (Fix price), as wel as “mircrotransaction” in Stripe. He talk about “group transaction” => a mecanism of intern credit. Pehaps, cheaper with payconiq. Pehaps, with the Oxfam shop, we could have cheaper prices.

Oxfam-Magasin du monde work with

  • ingenico for bancontact paiement at shop
  • Mollie for donation
  • they have some contact with payconic for phone paiement.
    I will have a meeting on thuesday 30 july with the comptability team to clarify this aspect.

Thanks you Rachel for this analyse. If I understand wel, it’s more robust and easy for OFN community if we use Stripe for bancontact than Mollie. But it cost more for hubs.

@Theodore I didn’t do anything except transfert @luisramos0 and @maikel 's analysis from github to here :wink:

But yes in a way you’ve summed up the situation. So the community needs now to decide if we want to pursue with stripe in order to deliver something more quickly (and possibly more stable - although this needs to be studied more closely) or if the cost for hubs is considered unbearable.

I have the feeling that we have a dev analysis but that maybe we lack a product one? I’m not sure I can handle this study currently, but I would be up to pair with someone on this. @lin_d_hop would you be available ?

For informations:
Oxfam-Magasins du monde have a contract with Ingenico for bancontact payment in the shops. Fee for transaction + subscription
Oxfam will use Mollie for donation services in a short time. Because we just obtain a certification of tax exemption for donation. Great news for us ! it’s a bit like hello asso in France.
Oxfam prospect payconic to pay with a KR code in shop with smartphone or eventually online (fee only on transaction).
Oxfam doesn’t know stripe without me.

Ok so I’m trying to see if we need to look at other payment gateways before taking a final decision.

Do you remember how you’ve found Mollie @maikel ? I don’t see it in:

The way I’ve searched for a payment gateway “challenger” so far is that I’ve looked at our current criteria which are:

  1. Is providing the Bancontact payment method
  2. Maintainability / deployment cost
  3. Price

With only this scope Paybox catch my eye because this gateway was mentionned by @MyriamBoure as “cheap” here : Integrate the cheapest EU payment gateway for big hubs : Paybox Direct Plus

But they have a really bad website :scream: that has badly been updated since they got acquired by Verifone. I guess they might be bad at criteria number 2.
The only way to get their fees is apparently to call them.

@MyriamBoure is Alterconso currently using this payment gateway?

What I like about analyzing them is that we could tick two boxes with Paybox: answer the Bancontact need AND answer the need for cheaper credit card transaction :muscle:
So I went on and asked myself what were the other needs / problems we currently have in the payment area and that are NOT covered by Stripe. The big winner here is ewallet / #splitpayments !

See How to offer Mangopay as a payment method to hubs? [Split Payments]

@lin_d_hop I didn’t dive into this conversation yet, but it seems that you were involved in it quite deeply. So if you remember anything that would prevent to add Mangopay (or something similar that enables an ewallet) to this spike please shout.
My idea is not to release an ewallet right away. My point is that if we are considering adding a new payment gateway to answer the Bancontact payment, we should add a payment gateway that can answer another need in the future.
I feel pretty confident that split payments will one day be prioritized. But maybe I’m wrong and maybe the overhead work of adding a new payment gatheway is too expensive in terms of dev time currently and we need to go to the easiest solution, which is Stripe.

Other criteria that I’m wondering about :
2. World coverage? Or do we want to target Europe only?
3. Age / weight of the payment gateways. Like if it is a startup we might need to wait a couple of years. We don’t want a payment gateways that can be dead soon.I’m adding this in the maintainability criteria.

So here is an updated table with all criteria and pros and cons:

Stripe Mollie Paybox Mangopay
Bancontact YES YES YES YES
Maintainability GOOD BAD BAD GOOD?
Price in EU 1,4 % + 0,25 € 0.39 € ? 1,8% + 0,18€
Price outside EU 2,9 % + 0,25 € ? ? 2,5% + 0,25€
Ewallet NO NO NO YES
World Coverage YES YES ? YES

Looking forward to any feedbacks!

I didn’t find Mollie, @luisramos0 mentioned it first on Github.

That’s a nice comparison. I’m not sure about the price label inside and outside the EU. The Australian pricing for Stripe is 1.75% + 30¢ for national cards and 2.9% + 30¢ for international cards. I think that it’s always relative to the country. Using an Australian credit card in Australia is cheaper than using a European card here. And using a European card in Europe is cheaper than using an Australian card there.

I also find it difficult to imagine how cheap or expensive these fees are when a fixed charged is combined with a percentage. I need absolute amounts. Maybe we can compare to Stripe. Mollie is cheaper than Stripe for all orders bigger than €10,00. And Mangopay is cheaper than Stripe for all orders smaller than €17,50. It’s actually more expensive than Stripe. We can also look at the fee of an average order of €30:

  • Stripe: 67c
  • Mangopay: 72c
  • Mollie: 39c

Mollie Bancontact support is documented here https://www.mollie.com/en/payments/bancontact

Thanks for this analysis @Rachel and those who did the spike :slight_smile:
I like your approach that we can try to do some work that will be at the same time the first step for another need we have, solving short term need and at the same time starting to solve another one (NB: if I remember well the second spike for paybox was also prioritized… so in fact it might solve two short term needs at once) … It might be more expansive to solve the Bancontact need, but will cost us less if we think that it answers also another need that if we do it separately later, will cost much more.

I think we should investigate Ingenico as well and compare with Stripe / Mollie / Paybox and Mangopay. They do offer multi-vendor split payment as well. I think they have been working with the Food Assembly before they mooved to Mangopay if I understood well, I met someone from Ingenico a year ago quite randomly.

About Paybox, I had a chat with someone from Verifone in 2017, I think we need to call again the cooperative bank using their system to make sure they still use it (Alterconso asked their bank but didn’t implement any use of it already so maybe it is outdated). It seems the coop bank doesn’t work with them anymore, but with Systempay.

So this being said, we said with @Rachel that we can go a bit further on her “product spike”, add Ingenico, update investigation on Paybox or other cheapest “subscription based” (and not per transaction) payment method, and submit this analysis to put some light on this reflexion and try to see path to get out of the payment sys need mess… One path I’ll follow on this analysis will be to analyze the payment systems proposed by Prestashop, Shopify, etc. and check them all, their geographical scope, price, etc.

I’ll prioritize that and come back quickly so we don’t block the path to move forward on Bancontact.

Ok so I’m probably half way through investigation, cheeck them here : https://docs.google.com/spreadsheets/d/1bJ4FherQbSgYmjqX-nw0a2emsjwyckIEPlZcazkG3nk/edit?usp=sharing

My foundings are that we are a hybrid model, between a marketplace like The Food Assembly and a marketplace builder like Prestashop, and we have simple sellers and micro-marketplaces (that we call hubs) that use our solution. That makes it hard to talk with payment solution providers…

In my investigation I check short term and middle term needs compliance so we have clues also for the other needs at the same time.

There is one “conflict” I’m not sure we can solve : multi-vendor escrow accounts like mangopay or stripe connect or paypal adaptative payments or… usually works with a % and fixed cost per transaction, which doesn’t answer the need for big sellers who prefer to pay a bigger fixed subscription per month and only a small fixed cost per transaction (which is what offer banks in general). So if we don’t want to integrate every bank solution to fit our big sellers need, we need to find some arrangement with a payment platform that understands that big sellers can’t pay so high commissions…

I started to discuss and negotiate with Lemonway. I have pretty big expectation with Ingenico and Verifone (Paybox) which are the two bigger players in the payment transaction market (they two manage 80% of the market apparently). Ingenico is already the system used by Oxfam for their physical shops. Verifone is the one we had in mind for the need of big sellers in France. Both are very international and seem strong and reliable (Verifone commercial teams are shit in EU as they are based in the US, but let’s see, I sent a message).

I have taken back contact with my Stripe entry point to see if we can negotiate (will explain them how they loose potential users who go to their bank solution). @lin_d_hop you did have a contact as well, how did that move forward ?
Stripe does answer lots of the needs, bancontact, split payments, etc. so if we can negotiate something for big sellers could be the easiest way to just keep on building on Stripe.
But we might have to implement just a third one who would have world coverage and a model closer to what banks propose to big sellers…

My aim would be for the OFN to offer payment solutions for small new sellers (a commission based solution like Stripe should do the job) and for bigger sellers (who want to pay more fixed cost but less % on transaction) and be able to offer the split payment as an option, as I think we would need to take that in charge at the marketplace level.

[Why ? Because else it needs every seller will have to register themselves as a marketplace given DSP2, and will have to pay fees for their own volume which will be higher than if we do that at marketplace level, making it accessible for small sellers, else only big hubs will be able to use split payments or prices would be prohibitive, but this needs to be discussed, I chatted about that with Lemonway and they will investigate our case]

I will have some calls with Stripe, Ingrenico, Verifone, in the coming days, will keep you posted of the update. Of course I only selected options that could support Bancontact, but investigate if we can find a solution that meet multiple needs at the same time of satisfying the Bancontact need.

Wahou ! Ok I spent an hour on the phone with the Ingenico kind and smart seller who spent the time to explain me all the “components” of the contracts proposed by the various actors in the ecosystem. I summed up everything in this document : https://docs.google.com/presentation/d/10dJjMwmLq274ecPByvhaCUUgUnNG7P7MUzRl_KkmBrA/edit?usp=sharing that I invite you all to read !

In summary : I want to wait to talk to Verifone, but Ingenico propose 3 types of services:

  • full service like Stripe (gateway + payment acquisition) > no real interest for us as we have Stripe
  • gateway only > very few actors on the market propose that, it means a hub manager can sign a “distance selling contract” with their bank (usually monthly small fixed cost + small fixed cost on transaction) and can only subscribe at Ingenico for a “gateway” service (small fixed subscription including a pack of transaction, then small fixed cost per transaction). That is usually FAR CHEAPER for sellers over a certain volume of trades. They have partnerships with almost all banks in Europe (payment acquisition in that case is done by banks). They can add on top of any gateway offer Bancontact opr propose it as full service (originally they are a Belgium platform !)
  • marketplace = holding account + breakdown to vendor accounts (what we call split payments, I clarify as split payments can mean the ability for the buyer to split his payment like half in cash and half in other payment method…). Usually they don’t implement it for markteplaces that trade less than 5 million €. He can try to argue and see, or we could implement that with them in some months when we have reached 5 million.

The “gateway” option seems like an integration pretty similar to what we have done with stripe, but easier as they don’t have to handle money acquisition in that case I guess… and would answer two new needs at once: Bancontact and enable sellers to buy distance payment service from their bank for much cheapers if they do big volumes (plus anticipated needs with no more effort : SEPA debit system and for sellers using POS as they have also a physical shop would make their like easier, see NB at the bottom). AND would open the door to satisfy the “split payment” needs as well, but when we are there we can choose between Stripe and them as they both do it. But Stripe will never satisfy the need for sellers with big volumes.

The guy I talked to sent me the technical documentation : Integration guideline. Choose e-commerce for the payment page in redirection mode or Flexcheckout for an iframe integration in our site.
Create a test account to test the integration. Technical support in france +331 70 70 09 03, support@ecom.ingenico.com
I don’t know if we can include that in the spike in progress to have some check of this option by a dev… @Rachel I let you check with devs if that makes sense :slight_smile:

To enable him to come back to me with the prices for gateway services that we could propose to our sellers (on top of stripe, for those who have big volumes and would like to go through their bank offer for acquisition), he asked me what are the majors seller use cases, and an idea of current and estimated nb of sellers and volumes of sales.

I prepared in the last 2 slides two tables that I would be very grateful if you could fill them up for other countries than France @lin_d_hop @Kirsten @Theodore @tschumilas @sauloperez or @Anna and @lauriewayne1. @Theodore you can add the nb/vol of Bancontact users as well in those estimates (maybe all your type one with full service offer ?).
Ping @Rachel for info.

If this is unclear with everyone, we can organize a dedicated call so I can try to answer all the questions, as I was answered by this guy to understand how it works…
After this interview I search a bit more and found some articles that helped me understand the differences between the roles, so the offers actors provide on the market:
-https://www.pagbrasil.com/news/differences-psp-gateway/
-https://tidalcommerce.com/learn/payment-gateway-and-processor
-https://www.firstdirectfinancial.com/payment-service-provider-vs-payment-gateway-whats-difference/

NB : interestingly, when allowing to separate gateway and acquiring, we will also allow hubs who also are selling in physical store and use a POS to simplify their contracts as they could have ina same contract their POS and ecommerce transaction with their bank, and only choose our gateway instead of the one proposed by their bank.

I had a go at filling in the spreadsheet.
To be honest I’m struggling to think about this right now. I’ve not heard anyone mention this for a while but that’s probably because I’ve only heard about performance related issues and small UX complaints for a long time now.
I’m sure if this is a cheaper payment method it might save the need to integrate GoCardless later in UK - though the people requesting GoCardless do so because they use it currently and hence it reduces learning, admin, transaction cost of changing.

GoCardLess feels like similar method to Stripe, I mean we have lots of small transactions so the capped thing to 2£ is not so useful for our hubs I think, and yes it is 1% instead of 1,4% and no additional fixed cost so it might be a bit cheaper… but it’s another full service provider, not like Ingenico I was mentionning offering just the gateway part to enable hubs to have a contract with their bank that would cost FAR less. I would be curious about what banks propose as ecommerce solutions to their customers in UK, do you have any clue @lin_d_hop ? If one of your hubs, or yourself, could ask a bank, about solutions and pricing, it would be interesting. I bet it’s same logic as in France… it’s very similar to physical payments, a physical store “rent” to the bank the payment terminal and pay a subscription for that + some small fee per transaction, but no %. Banks usually offer the same type of contracts for digital gateway, which is the equivalent in digital world of a physical payment terminal.

Ok just got off the phone to Barclays to try and understand this.

Although there is much to still get my head around it seems like we’ll start to save significant money on transaction fees for enterprises trading over 500k via card payments per year. UK don’t have any users at this scale and our only potential user at this scale want to use GoCardless as their solution.

Sounds like something that will certainly help enterprises at scale. Though I wonder if OFN is up to the task in other ways currently. I would want to be sure OFN pricing (eg pricing tables), performance and product lists are appropriate to work with users as these scales . The scale required to make this a viable alternative make me think we’ll run into a number of other blockers along the way.