Make life better for communities that can't use Stripe

[jfly]

Right now, communities that can't use Stripe end up directing people to some third party website, and then the competition managers have to manually approve registrations back on the WCA website.

Long term, I think there are 2 approaches we can take here:

1. Build APIs that allow people to leverage some useful features of the WCA website for registration, but maybe the whole api flow actually occurs somewhere else. There are a lot of hypothetical ways to divide up the responsibilities here, and I'm not sure what the best solution would look like. This is tangentially related to #3437.
2. The WST could aim to support all forms of online payment that organizers need.

While I'd love for 2) to be the case, historically, the WST hasn't been very responsive to people's requests for alternative payment schemes.

Short term, I would like to use this issue to track the various communities that can't use Stripe, the reason why, and alternatives that would work for them.

[Laura-O]

For several countries in Western Europe, the problem is not that they can't use Stripe, but that they do not have or do not want to use the payment methods which are offered on the WCA website (= credit cards).

In Germany and other surrounding countries, people do either not have a credit card or only use it on special occasions. Paying a fee on a random website is definitely not such an occasion and is usually considered as insecure. For paying online, popular services here are giropay and klarna, as well as PayPal. So one way to improve the situation would be to add more of these methods to the stripe implementation on the WCA website.

[pedrosino]

Stripe isn't supported in Brazil, for whatever reason.

I don't have data on how many % of people have/use a credit card, but I'd say not everybody. The preferred option for some is a ticket/billet/invoice that you can pay with cash at the bank.

Paypal works here and we have a few "domestic" options that are similar* so if those could be integrated into WCA registration it would be awesome.

I developed a Paypal IPN listener for WC2015, but it used php :P I also don't remember much, but I was able to automatically update my database with payment information (a user id and the amount paid).

[trungams]

Hi! I just happened to see this issue, and would like to put that Stripe isn't really a thing in Vietnam.

In my experience, online payment in our country has not been popular until 2 years ago, and there isn't exactly one system that can be considered most widely used. Many people still prefer to use cash here, so the long lines of people waiting to check in and pay often badly affect our competition schedule.

I'm doing some research on a reliable online payment system in the country, and will report back when I find something.

[saranshgrover]

One of the most important things to decide here is what payment methods to support. We have limited time so it is important that we pick something that gives the max reward (i.e used by most locations). Just by a quick and small sample size, this seems to be PayPal. But perhaps some community feedback is important before we proceed

[KerrieJarman]

Thanks @saranshgrover , I will approach senior delegates and ROs to understand what the preferences are and report back.

[KerrieJarman]

I have spoken with team leaders and seniors, there is a bit of variety here but it seems to be that PayPal is a popular and obvious choice. Some have requested an open gateway so that multiple payment methods are available.

It would be good to understand the limitations and ramifications of supporting a wider range of payment systems/platforms.

I have started a project, to help guide the development. Also marking as high priority.

[EdHollingdale]

Is there a way to make this "extra high priority" - aware that it is a big task which realistically probably won't be done until we have a dedicated WST person taking a look at it. However, recent experiences make me want to do this not just to improve the experience for places that can't use stripe, but to also not 'put all our eggs in one basket' with payment providers (especially stripe).

[FinnIckler]

I did some research on PayPal integration a couple of months ago and the problem is not the integration, but getting the money to the organisers. PayPal does not support a multi Tennant setup like stripe where anybody can just link their own personal PayPal account to get paid into. Instead it needs to be specific business accounts. To fix this we would either:

• have a central WCA PayPal and distribute the money
• have PayPal business accounts for every RO and they distribute the money
• make organisers sign up for PayPal business accounts and have a process to onboard them into our registration system (probably some API keys and co) This all seems to be not great solution and this is because PayPal is not intended to be a multi Tennant solution with variable accounts to pay into like stripe.

I'm not saying these are 100% blockers, but we would either need to change the ways organisers are paid or make the organisers do some fairly specific sign ups and configuration first

[gregorbg]

Thanks Finn for the summary! In essence, it means that with Stripe we can "pull in" organisers accounts on the fly. With PayPal, this is not possible and linking accounts implies complex code changes every time a new account should be linked. It is simply not feasible.

Another issue I'm having with this from a Team Leader perspective are the stakes involved in this change. Money is usually perceived as a very crticial aspect of any system and if we make major changes to the current system (which we would have to for this issue) we risk creating big incidents.

I am not even talking about losing large sums of money. All modern payment gateways and money transfer systems have several redundancies and security measures baked into the very core of their functionality. I'm talking more about messing up parts of the integration that determine how payment information is used on our website. The easiest example would be messing up the payment date, so that competitors think they paid but the integration throws an error somewhere and so they miss the competitor limit. In the meantime, other competitors can sign up and it is perceived as though someone lost their "rightful" spot to compete with registrations filling up so quickly these days... And don't get me started on taxation and accounting for several different, incompatible or competing gateways (like Stripe and PayPal).

Don't get me wrong, I want to help and make life better for these communities, but with the current structure of individual volunteers who contribute between 5 and 10 hours per week and who live in different timezones (making team work much more difficult to coordinate) I don't see how this can be achieved. This is a corporate-grade issue, if we want to solve it we need corporate structures with paid employees/contractors/contributors. Simple as that.

[EdHollingdale]

This is a corporate-grade issue, if we want to solve it we need corporate structures with paid employees/contractors/contributors. Simple as that.

Agree with that - this is a huge task that won't get fixed until we can pay someone to do it. I was just bumping to make sure it is up there on the WST's long long list.

For the options listed:

have a central WCA PayPal and distribute the money

There is zero appetite for this from a WFC perspective. The reporting and administration would be a nightmare, could create sales tax liabilities in multiple jurisdictions, and would still require a certain amount of 'organiser onboarding' for them to receive the payments.

have PayPal business accounts for every RO and they distribute the money

This makes more sense to me. I think we want to go in the direction of ROs (or sub-ROs) managing finances for all competitions. Creating special "RO accounts" that get linked to competitions and then onboarding paypal integration for a finite small set of ROs who want it would be the best solution in my opinion. For the most part ROs will want to use stripe as it has lower fees than PayPal, so it would just be there for communities where stripe is not supported or as a backup option.

[dunkOnIT]

Removed high priority label as it isn't something we can work on / prioritise in isolation.

[Laura-O]

Hi everyone,

after spending several hours on matching Paypal payments with registrations, I wanted to know if there is any news on this issue.

I understand that adding Paypal to the WCA website is not trivial, but I remember several discussions about adding more options to Stripe. Stripe supports bank redirects, i.e., redirecting customers to their own bank accounts, they log in, pay, and are then redirected back.

The most popular service in my region is Sofort. According to the documentation, it's also supported in several European countries.

Did you ever consider adding this to the current stripe implementation? I assume it would require a few changes, but it would probably still be a much smaller change than adding a completely new payment service.

Best Laura

[gregorbg]

Hey Laura,

there is a draft proposal pending at https://github.com/thewca/worldcubeassociation.org/pull/7379. Implementing the workflow from that Pull Request would automatically enable more payment providers as determined by Stripe, for example Sofort (and also others).

In order to proceed with the implementation, we need to figure out certain design decisions in the underlying business logic. There are also breaking compatibility issues between our current payment workflow and the new proposed workflow from the PR that have to be considered.

This is currently somewhere in the medium-high priority rankings on our agenda. I'd expect an implementation some time during Q2 this year. Furthermore, you are free to contribute to the discussion over on the linked PR if you would like :)

[FinnIckler]

Hi Laura, this looks like an easy win to get more payment options. I however immediately see two Problems with it that require a lot of developer attention (which is at the moment not feasible):

• This requires Stripe's PaymentIntent system which we currently do not Use (Gregor started some work on it in #7379)
• This is a delayed Payment system, while we currently use Stripe has an immediate Payment system only. This will a) break a bunch of stuff and b) needs a complety new system on when we consider a registration paid. We don't want to punish Users who's Bank takes longer to process payments, so do we delay accepting anyone for a week, or even two weeks?

I know it's a pain right now, but sadly this is not the easy solution as it looks at first glance.