search

joomla / joomla-cms

Home of the Joomla! Content Management System
https://www.joomla.org
GNU General Public License v2.0
4.75k stars 3.64k forks source link

[4.0] Common Payment API #24746

Closed nobicycle closed 5 years ago

nobicycle commented 5 years ago

Is your feature request related to a problem? Please describe.

8000 extensions in the JED. Probably several hundred payment gateways in existence globally. 8000 x 400 = 3 200 000 = 3.2 million potential gateway pieces of code.

Financial processing is probably the most highly sensitive of all processing done within Joomla, and yet it is dispersed among innumerable code plugins. The risks are:

Describe the solution you'd like

Choose one of the Open Source Common Gateway's that have been offered to the Joomla community and incorporate it in core Joomla. Candidates known to me are:

  1. Payage https://www.lesarbresdesign.info/extensions/payage

2.Techjoomla https://techjoomla.com/common-payment-api

ghost commented 5 years ago

Please report at https://github.com/joomla/jed-issues/issues/new

Closed as wrong Repo.

nobicycle commented 5 years ago

Closing this within 200 microseconds is impressive. However, the issue raised was about the core. Not JED.

ghost commented 5 years ago

@nobicycle sorry, reopened for Reason stated above.

alikon commented 5 years ago

IMHO this matter should be re-considered for inclusion in 4.x at least to give some basic API given we already have some proposal like https://techjoomla.com/common-payment-api standing from 2012

mbabker commented 5 years ago

👎 because Joomla seems to love re-inventing the wheel, Joomla does not have the resources to build and maintain its own payment gateway APIs. There is nothing wrong with encouraging developers to utilize libraries such as Omnipay or Payum, or utilizing the SDKs of the gateways they do support, but this is not core territory.

Bakual commented 5 years ago

As Michael already wrote, there is no way we could even remotely support that, nor should we. Use one of the solutions which already exist.

dgrammatiko commented 5 years ago

@mbabker is right not only for the reasons stated above but mainly because the W3C already solved this problems for us (devs) with the payment API: https://caniuse.com/#feat=payment-request

https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API

It would be nice to check the state of the web periodically, things do evolve...

Fedik commented 5 years ago

@nobicycle when you doing your Shop extension, set dependency to one of existing payment extension, and if everyone will do that, then your problem are solved. Easy, no?

There also many PHP libraries for it: https://github.com/thephpleague/omnipay https://github.com/Payum/Payum

In the core it will be dead and useless piece of code. Maximum that it could be it like com_weblinks, separated component (that actually can be just wrapper to one of existing library). But be honest, who will support it?

Bakual commented 5 years ago

I'm closing this issue for the reasons stated above.

nobicycle commented 5 years ago

"nor should we use one of the solutions which already exist."

That was done with Custom Fields by Digital Peak - how come? A fantastic new feature by the way.

No core support is needed.

  1. Payment Gateway service providers would publish API snippets to interface their gateway.
  2. Developers would use the API to develop their extension IN a safe, simple and efficient way.

It is like an n-n interface table.

Instead of innumerable of pieces of gateway PHP we would have a countable number of safe and well developed pieces. Currently, payment gateway service providers will not develop php interfaces to Joomla because their are hundreds/thousands of needy extensions. But they would do so if an API existed. The reasons given for closure are invalid.

nobicycle commented 5 years ago

@Fedik Hi, Custom Fields is supported. Why not a Gateway API?

"Payment provider -> API" would be written by the service provider, for sure, they only need to write one bit of code to potentially engage all Joomla extensions.

"API-> Extension" would be written by the Joomla developer, but his task is simplified in the extreme compared to to days situation.

I listed those two particular API's because they already are engineered for Joomla.

At minimum, if Joomla Leaders would draw attention to this way of doing things then perhaps those Open Source Joomla solutions might get noticed.

Bakual commented 5 years ago

Custom Fields was a component that was donated by the developer. It is something which has a benefit for most components (not only shopping ones). Also it's simple to maintain as there are no external dependencies. So it's something completely different.

nobicycle commented 5 years ago

" Also it's simple to maintain as there are no external dependencies." Nor would their be any with a common API.

Payment Gateway service providers would publish API snippets to interface their gateway, unless they were very stupid.

This is the main point - publishing some small api for payment gateway service providers to interface to. So they can write once only.

nobicycle commented 5 years ago

Custom Fields was a component that was donated by the developer. It is something which has a benefit for most components (not only shopping ones).

On the Jed, of the top most reviewed extensions, the ones not developer oriented (forms, backup) are:

4. Acymailing

#6. Virtuemart. aka Shopping

So it seems shopping is pretty high up on the list of peoples concerns.

brianteeman commented 5 years ago

Acymailing is not an ecommerce extension

Bakual commented 5 years ago

Payment Gateway service providers would publish API snippets to interface their gateway, unless they were very stupid.

I'm afraid, but you overestimate the importance of Joomla for payment processors. They may do that for Wordpress (I don't know) with it's high market share, but not for Joomla.

Beside that, there already exist such payment libraries which are independant of any CMS. Those should be used as written multiple times already. And I'm sure Virtuemart and other such extensions are already doing that just fine.

mbabker commented 5 years ago

Payment Gateway service providers would publish API snippets to interface their gateway, unless they were very stupid.

This is the main point - publishing some small api for payment gateway service providers to interface to. So they can write once only.

Those already exist. Most payment gateways provide SDKs for working with their gateways. It is on the developer to integrate those SDKs into their project. It's not a "Joomla creates a payment gateway API and PayPal and Stripe and Authorize.NET turn around and write code to support Joomla's API" workflow (most of the gateways don't write the integrations for ecommerce solutions like WooCommerce, Virtuemart, or Sylius either). at most you're going to find tutorials on how to integrate their SDKs into your PHP projects and maybe some specific examples for integrating into existing ecommerce solutions or examples of plugins that already do that integration.

EricdeWaal commented 3 years ago

Actually, my idea in J! 4 #31172 is a lot different from the above. No complete payment solutions to be built into Joomla! Just a core layer to interface between e-commerce extensions and payment plugins. So each e-commerce extension can use each plugin. Plugins can be written either by the e-commece authors, or by third parties.