[SPIKE] Bancontact payment method

[RachL]

Description

This issue covers a spike of the Bancontact payment method. Bancontact (ex Mister Cash) is the leading payment method used in Belgium / Netherlands / Luxembourg (Benelux).

Acceptance Criteria

After the spike we should:

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

[luisramos0]

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

I am pretty sure it's better to integrate through Stripe because 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, I have not investigated that. Also, I am not sure yet but this redirect logic will also be useful for PSD2 #3927

Apart from Stripe, there are many other payment gateways that integrate with bancontact: https://www.bancontact.com/en/professional/payment-button 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.

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 We will ignore recurring payments for now.

Conclusion

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.

So, question 1. I dont see why we would use another gateway for this if stripe supports it question 2. list of tasks above, webhook and validation part being the most novel thing to do. My estimate is L, I'd guess that a dev would take at least 40 hours to do this.

[luisramos0]

@mkllnk I think you will know a few thing about this. Can you please review? Thanks!

[mkllnk]

Interesting. I found this confusing at first. Here are some of my learnings:

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.
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.

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

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. Here in Australia, many food hubs would say that they can't afford Stripe. Is that the same in Belgium? And I didn't find any separate pricing about Bancontact via Stripe.

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.

I think we can implement either. They both have their up and downsides.

Conclusion

I personally would prefer to use Mollie.

• It's a lot cheaper.
• Mollie supports much more than Bancontact. We would win access to a new provider as alternative to Stripe and Paypal. That reduces dependency.
• I value diversity. If Stripe breaks, we still have Mollie. If Mollie breaks, we still have Stripe.

[luisramos0]

Great info, thanks @mkllnk

I think diversity and price are very important but I dont think mollie is a good option for us, right now because:

• mollie spree gateway only works with Spree 3.5 or newer and even if we find a way to connect this will be one more spree dependency for us...
• 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)

[mkllnk]

Sounds to me like we want both. First implement Stripe to have a quick solution and then make it great by implementing Mollie or similar. :smile:

I agree that implementing the Stripe version is probably quicker. But I also didn't think that implementing a new payment method was so complicated. I haven't done it yet though!

I had another look at https://github.com/mollie/spree-mollie-gateway and I don't want to include it into our code. It suffers from spree decoritis: Sorry, I'm not trying to discredit that project. It's just that we aim to be less tightly coupled to Spree. And it's a nice reference for us how we could implement it. They use https://github.com/mollie/mollie-api-ruby which looks extremely simple, no dependencies.

It's a complete guess. But let's say Stripe takes 40 hours to implement and Mollie takes 80 hours to implement. And I outlined the fees above. Do you think that is enough for the rest of the team to base a decision on?

I think we have done the research and we can't really estimate it much better. Now there is the discussion between Belgium and the global budget pool.

[luisramos0]

yeah, thanks for the help with this one @mkllnk ! Moving to test ready.

[RachL]

@luisramos0 @mkllnk where should we do the discussion with Belgium? here or discourse? I have the feeling that if we close the issue we would just loose the result as searching on github isn't always great.

[luisramos0]

an extra question coming from what Maikel said would be: 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.

Hi @RachL I think we can close the spike. the discussion will be a call or a discourse thread right?

[RachL]

@luisramos0 @mkllnk I made a wiki here: https://community.openfoodnetwork.org/t/bancontact-payment-method/1694 please correct if I've missed anything.

Closing the discussion here.

[luisramos0]

awesome!!! thanks.