Payments Roadmap about solidus HOT 7 CLOSED

👍 on removing the state machine and moving source construction around.

I also want to get rid of sale transactions, because I agree that they're wrong. However, it is a pretty invasive change for our users, so I want to make sure we have a good migration guide.

from solidus.

I also want to get rid of sale transactions, because I agree that they're wrong. However, it is a pretty invasive change for our users, so I want to make sure we have a good migration guide.

It is, and I fear that there's some gateways which only implement purchase.

I think some users will be using auto_capture just to capture on complete (which is what it sounds like it does) rather than because their gateway requires it.

from solidus.

Maybe adding a capture_on_complete and deprecating auto_capture would be a good transition

from solidus.

One thing that we needed was the ability to create payment sources without an associated payment, so we could allow users with subscriptions to switch their payment method between "orders".

Also, with the European payment sources, we needed some kind of abstract idea of a payment source, and a #payment_sources association on the User model that supports polymorphism. I know polymorphic associations are a pain, but here I think they actually make sense. There's a PR on the Spree repo already which probably won't get merged anymore: spree/spree#6831

I'm really not set on the details here, mostly I'm interested in something like this being possible without too much patching.

from solidus.

EDIT: I may have spoken too soon as I see that payments without payment sources already seem possible. However since my understanding is limited at the moment I'm leaving the original message below in the hope that it contributes anyhow.

I would really like to see work on this or see how I could help with this. I've currently been trying to roll my own subscription service, mostly because most that's out there is aimed at using Credit Cards. Solidus can take a lot of work out of my hands in building my own service but I would need support for extendable payments that don't use credit cards.

The payment methods I would need (and would be willing to help implement as I would have to do that anyway) are iDeal (used by 85% of Dutch online shoppers) for one-off payments and SEPA which is used for recurring payments.

I must admit I'm not familiar with the current state of Solidus payments but one thing that I see as a potential problem is the requirement for a Payment Source (unless I misinterpreted this issue). For example, iDeal is trusted and used in the Netherlands precisely because it is not a payment source. (SEPA comes closer to this, especially with Stripe's implementation which I would like to use).

iDeal works roughly as follows, which is why I think it doesn't qualify as a payment source:
The website requesting a payment contacts its iDeal service provider (usually their own bank or an intermediary) and requests a payment with a description for a certain amount. It then receives a token identifying the payment. Using this token it redirects the user to the website of the user's bank where the user can complete the payment in a trusted environment. After the payment is completed (or cancelled) the user is redirected back to the merchant's website. The earlier token that was used to identify the transaction can then be used (either in webhook or query form I'm not sure, both should be possible) to retrieve the status of the transaction.

As described I don't think iDeal constitutes a payment source but rather only gives information about whether a payment was succesful or unsuccesful and allows the website to act accordingly.

As stated I would be happy to help in see how payments could be implemented. In other frameworks that I have used I think this would be a great place for polymorphism. Having a Payment interface class that can be used to query the status of a payment and complete a payment and having various subclasses that actually implement the inner workings (e.g. storing credit card details and billing, redirecting to Stripe for secure credit card handling, redirecting to iDeal or using SEPA for a recurring charge).

from solidus.

@Kingdutch in my opinion, iDeal does constitute a payment source, maybe something like an IdealWallet, especially if there's any way of re-using an iDeal payment source for a future payment.

The payment interface class you're talking about exists already, it would be Spree::PaymentMethod.

from solidus.

Closing due to staleness

from solidus.