Implement the initial payment functionality

Will this integrate with https://www.drupal.org/project/payment_commerce #2634842: [META] Port to Drupal 8

There's great points about making offsite payments in payment module that already have 8.x version #2683795: [META] Add offsite payment methods support
Suppose commerce could collaborate with current implementation

Hi

Good points

I have started this issue for payment module with goals to simplify real payment methods implementations.

I want take your attantion on the following items.
1. I think we need add generic external result status plugin\method for offsite payment methods. Maybe it will be better make optional visitor visual page for each payment status. (I mean Complete/Cancelled/Failed/(Partially) Refunded)
2. Results urls on any real payment methods shoud not be dinamic like /payment/< hash >/return but /payment_method/< external status >.
3. I think we must use per payment methods result urls sets becouse in most cases we can't identify if data recived from GET\POST (ie from Request() ) is corresponding to certain payment method. I mean if Payment Id from POST is 12345 we need also validate if this payment was started with rigth payment methods.
4. Many offsite payments methods are not pinged site on any transaction statuses except success so we need "fallback" flag for payment status If this flag is TRUE for payment status it means that we need to emulate IPN like procecessing. Owervise payment transactions on site will stay on panding state even if payment real state must be fail.
5. We must handle multiple instances of the same payment methods with different configuration not in the way like that was in commerce 1.x (i.e. almost all contrib payment methods for commerce 1.x are not support this functionality because it not transparent for contrib developers)

More details you can find in this issue
Also can you describe me how I can help with propper payment methods implemetations in commerce 2.

No, Payment module is its own thing.

A rephrase of my question: why not focus on integrate with payment module? And make that module rock too.

I'd think that is a great idea too but for some reason the Drupal Commerce maintainers have decided against using Payment as the main payment platform for Commerce 2.x #1789160: Make Commerce 2.x depend on Payment.

Maybe this can be reconsidered, limiting the time that will pass before we can start processing payments for Drupal Commerce in Drupal 8. :-)

@ricovandevin thanks for the link.

Using Payment would require me to rewrite it

@bojanz I'm confused about the rewriting stuff after reading Xano reasoning in #1789160: Make Commerce 2.x depend on Payment and frankly I don't get it. It could be a great marriage inline with the DC effort to create reusable components like intl, pricing and tax. But I've no clues on impacts for DC using Payment. It would be great but we all need a working DC asap :-)

@bojanz, any ideas on production ready release for Commerce, I'm trying to hold off some clients at the moment. I'd hate to start a D7 commerce site build now and see a D8 prod ready release half way through.

Sorry, wrong issue queue.

@kafmil: oh no, good issue queue - I wanted to ask @bojanz about the state of Payment API today anyway, just haven't seen him on IRC today at all :D

Last weekend I got hacked to cleanup/review api for off site payment modules in sendbox https://www.drupal.org/sandbox/niko/2685859
I think payment method configuration could be unified and compatible across both modules at least for ones that receives IPN requests
The general points are in issue summary #2683795: [META] Add offsite payment methods support
Any feedback welcome)

For the last two weeks we've been working on IEF issues related to translations and revisions, so no major announcements here re: the payment API. As someone who had to manage a major project release before (Commerce 1.x : ), it can be somewhat discouraging to be asked for updates when none are given. Bojan will definitely update all issues as they're addressed, and while he'll be switching back to Payment work now that the more fundamental blockers have been dealt with, there's no guarantee that other fundamental (or core Drupal) issues won't come up that delay its finalization.

Right now I wouldn't expect a first pass at the payment API to merge in for at least a couple of weeks (basically, the time we were delayed).

(Also, thanks for sharing andypost, but we don't have any intention of depending on the Payment module.)

@bojanz: fyi https://github.com/agoradesign/commerce/commit/51407606dd5d9c0a12377566e...

I have some architectural/conceptual questions. I've looked into the payment branch of the Github repo.

A payment gateway defines via annotation a single payment type that is supported/belongs to the gateway. As far as I can see, credit card will be a default payment type delivered with commerce. This is a trivial one. But when I think of third party payment gateways, that handle multiple different payment types (credit cards, direct banking, PayPal,...), how would I model this? Should I define an own gateway for every possible payment type, or do I rather define and reference one payment type, that unites all different real world types into one definition?

Hi all

I want to point a use case discovered recently. On Stripe payment method it is possible to use 3D Secure to limit any fraud.
cf : https://www.drupal.org/node/2717383

This is a In-Site payment method, but to type the secure code we need to be redirected to a page provided by a bank using form posted using an additional like checkout step as for Off-Site payment method.
If secure code is refused we need to go back to the checkout step which display payment methods to try again, eventually with a different credit card or payment method.
If the code is validated, the initialized payment transaction is validated.

Currently in Drupal 7 it's possible but really hard to implement such behavior.
It should be a very good thing to keep it in mind while creating the architecture of this module.

My thanks

That's a good point. The 3D Secure thing causes headache all the time. We have a customer running a Magento store. The payment extension opens the 3D secure form after sending the order :DD

Just an FYI, looks like Bojanz has been busy: https://github.com/drupalcommerce/commerce/commit/dece89ae59c075095654c5...

Thanks for the hard work and things are looking good! Excited to read any notes about the status of this branch vis-a-vis getting others in there to test and improve.

bojanz updated the payment branch on Github today, but still unfinished. For everyone, who wants to start working based on that anyway, a patch might be easier to integrate into deployment than code hosted on a specific branch -> here's a patch covering the current state of work, working against the current dev branch

@bojanz: as you're not on IRC at the moment, here's a very quick feedback of the recent changes:

• there's still one bug in the workflow definition: the "to" state of "refund" must be named "capture_refunded"
• commerce_order and commerce_payment now have a circular dependency on each other in their info files
• something I often struggle myself with designing more complex system: I dislike the new dependency of commerce_order on commerce_payment. It's manageable though, but not pretty - think of very simple (b2b) order systems without any payment, or even projects, where Commerce woudl be a good base, if you need just products and the cart feature, but no real checkout and payment
• although it interestingly worked to put an item in my cart - why payment_gateway and payment_method fields on order entity marked as required? That's impossible to fulfill, as long the order is a cart and not yet transformed into a placed order

First, big thanks to bojanz and the rest of the Commerce Guys and maintainers for their hard work. I've been working on some e-commerce-y projects at the moment and am trying to help where I can in the issue queues. You guys are all over entity, address, wow!

Anyway, to this point:

something I often struggle myself with designing more complex system: I dislike the new dependency of commerce_order on commerce_payment. It's manageable though, but not pretty - think of very simple (b2b) order systems without any payment, or even projects, where Commerce woudl be a good base, if you need just products and the cart feature, but no real checkout and payment

The bolded piece above is an interesting concept for me. I am working on integrating paid memberships to a central "membership hub" that manages access to affiliated sites. I have created a dependency on commerce_order so I can take advantage of the content type and also the workflow model. However, all the transactions and recurring payment magic happens at our vendors - both of whom have very different (read: archaic) data models. I don't need to reflect the payment attempts or data in Drupal, just the status of the current "order" in the foreign system.

Having the other modules enabled and unused isn't a huge deal, though not ideal. Just a vote for a more decoupled use case.

rebased the patch

rebased the patch

added the missing "payment_gateway" field to payment entity

@agoradesign - You can get a current patch for a branch by just appending .patch to the comparison; e.g.:

https://github.com/drupalcommerce/commerce/compare/payment.patch

Thanks Brad. I know. But that's too volatile. Any rebase etc changes the patch. So your builds may break.