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

Closed as wrong Repo.

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

@nobicycle sorry, reopened for Reason stated above.

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

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

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.

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

@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?

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

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

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

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.

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

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.

Acymailing is not an ecommerce extension

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.

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.

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.