Vidya Sagar
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
- Shipping and Billing address Component
- Delivery Methods/Shipping Methods Component
- Payment Methods List Component
- Discount Coupons Component
- Tax Component
- Total/Grand Totals Component
- Place Order Component
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.
Boegie19
Vidya Sagar: I agree here. I don't see strapi do it since there main focusing is improving there product for all users and not adding a new user category to strapi.
the comunity would most likely not do it since to get it in the plugin maketplace it would have to be open source and there would be no money to gain from it only money and for 1 person it would be to major of a time sink
So If I am onest I don't see this happen unless a big group of community users gets together to do it.
Vidya Sagar
Boegie19: Indeed, In fact, that's one difference that Magento 2 has with it's marketplace when compared to Strapi. They allow the vendors to make money off of the modules. So if a third-party company or an organization makes an extension for Magento 2 and puts it up on their marketplace (which has it's own review process as well for quality check), then they are allowed to make money from it both on the marketplace and on their own website. I am not sure if Adobe makes money from the sales, but I reckon they do.
I think that's more of an organization-level decision that only Strapi Team can make, to see if it is worth pursuing and allowing others to make money from it. I personally think that this approach helps create an ecosystem around the platform, as it provides an incentive for third-party developers to explore and extend functionality for the platform. However, for the time-being, the juice may not be worth the squeeze.
C
Contact
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
D
Davidjeba D
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
Emilie Ringwald
Stripe collaboration for payments for stores 😁