I have worked with e-commerce solutions and payment methods as well and I think a payment methods integration is not as straightforward as mentioned here. There are usually a lot of requirements in requests that specific payment providers have for each payment method and different ways in which they expect the payloads and REST/GraphQL requests and handle webhooks, authorize and capture tokens and more; And not to forget PCIe compliance.

So, what can be done in Strapi is something like Magento 2, wherein Magento 2 provides a basic interface to work with. There is a checkout module in Magento 2 which handles the frontend rendering of various aspects of Checkout in a one/two/three step process of the quote with components such as the

All these components can talk to each other and share data which eventually affects states. For instance, shipping address could affect which shipping/payment methods are available for that particular country/region, or whether ''Place Order" Component can allow clicking on the place order button or what the action would be for the place order, depending on the selected payment method etc..

There is a quote module which handles important aspects of the checkout such as the order ID, cart ID, address, selected shipping methods and payment methods and updates it for the particular customer in the customer entity. This can be accessed by other modules such as payment methods or shipping methods which could handle various aspects such as tax, rewards etc..

Now payment methods is a complex part of a checkout and Magento 2 has various third party support for each which allow for both redirect/ in-flow type experiences. But for getting started Strapi could have a simple re-direct type payment method wherein there would be radio buttons for each payment method and strapi's job would be to only render the method list. The logic for what happens when a user clicks on the payment method and tries to place an order can be handled with seperate modules that the individual payment methods expect. This can be either written by Strapi team or by the community/third party developers. The presence of Quote and Customer Entity and modules would help standardize the process for vendors and developers for writing modules for payment methods.

If Strapi Team were to write popular payment methods such as Stripe, PayPal, Authorize NET etc.. then it would help to massively to boost Strapi's presence in the eCommerce space. This is what Magento 2 has currently done and I think it works well for the platform as they have provided support for the popular payment methods themselves and let others continue developing from there.

They also have basic things such as "Cash on Delivery" and "Bank-in Slip" shipping methods which is quite useful for merchants, but that's I think that's a topic for another thread.

Having worked with ecommerce + strapi:

Many payment providers have a few dozen variables to accept to charge a single payment. (they take info like tax amount, rate, order items, order item variations, etc, etc) because they use this data for accounting. The actual implementation of a wide variety of payment providers relies on having access to these variables. Given the nature of how developers use strapi the configuration page for even one provider would be pretty complex, not even taking into account having to create a "universal" system that can support multiple. You also need to ensure you're passing values into payment provider apis as certain data types because most of them are explicitly typed using SOAP apis. There are a lot of different requirements for each payment provider and having to ensure that whatever custom content-type has all the values necessary is a huge hurdle all on it's own.

Personally I think payment plugins should be created (providing a place to have a basic config ready to go) but they should leave 90% of the full implementation to the developer because there are a lot of moving parts and, usually, additional custom business logic involved with accepting payments (creating an order as a result of a successful payment for example).

A centralized system for this would be GREAT but I feel it will just be nothing more than a wrapper that wraps a wrapper, wrapping a wrapper of an old SOAP api. Which to me seems like a maintainability nightmare.

The actual implementation of each provider is really straightforward when working with node directly: typically charge(40+variables) refund(id) etc making the tradeoff here pretty one sided. I've personally implemented a couple different payment providers with strapi and it took ~10 hours including testing.

Just my two cents

Name it "PayStack"

1.Stripe, Worldpay, ApplePay, AmazonPay, GooglePay, etc

2.Coingate, Coinsgate, Bitpay etc

Payment Modes

1.Fullpayment

2.Pre-Payment

3.Partial Payment

4.Recurring Payment

5.Split Payment [Multi-User]

6.Crowdpayment

7.Pay to Multi Accounts etc

Stripe collaboration for payments for stores 😁