The PaymentElementGateway has been refactored to support additional payment method types in #3408951: Refactor Stripe payment element for additional payment method types. At the same time, this change forces us to implement specific plugins for every supported payment method. (see https://git.drupalcode.org/project/commerce_stripe/-/commit/bf118321d3fb...).
This means, that we have to manually implement the Link Plugin, to actually use Link. See #3421392: Add PayPal support to Payment Element Gateway for a similiar implementation for PayPal.
Implement the Link plugin.
Before we start:
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
grevil commentedThe Paypal integration was already implemented through #3421392: Add PayPal support to Payment Element Gateway this issue only targets the Link implementation now.
Comment #3
anybodyWould definitely be a very useful feature! +1
Comment #4
anybodyFYI: We just had a client who even "successfully" (on the Stripe side) paid with Stripe Link.
After the payment was successful, this exception happened: #3561321: The selected stripe payment method type(stripe_link) is not currently supported
So seems we might not be that far away from a successful implementation?
Comment #5
smokris(Adding parent issue to help organize the various payment method additions.)
Comment #6
tomtech commentedDevelopment and testing is in progress.
@anybody, technically any payment method type on the Stripe type could work successfully, but we will throw an exception when it is returned if a corresponding payment method type is not implemented.
This is for multiple reasons:
1. It may need special handling. (e.g. We need to skip updating the billing information for PayPal, CashApp throws errors when attempting to reuse the payment method, even though it is supposed to support reuse, etc...)
2. We need to store different field data. Each payment method type has different fields they return
3. We may need to implement additional javascript to support that particular payment method UX.
etc...
We also test each payment method to ensure that it works for:
1. anonymous and authenticated users
2. Auth Only with Delayed Capture and Auth+Capture
3. Single Use vs Reusable
4. Refunds/Voids
5. Behavior when cancelling the payment (Especially for those that redirect off-site)
etc...
It would be nice if they all worked consistently, but there tend to be little idiosyncracies with each one. :)
Comment #7
anybodyThank you very much @tomtech - totally makes sense!
Once ready for review, we're happy to help testing.
Comment #10
tomtech commentedLink payment method type has now been implemented.
Note: it will only be present if "setup_future_usage" is set to "off_session".
Comment #12
grevil commentedGreat stuff @tomtech! Thanks a LOT!
I guess, this information should be part of the README.md? Is this only required for Link, or are there any other payment methods, which are only present with specific configurations? In that case, I would create a follow-up issue, adding that information in the README.
Comment #13
anybodyRe #12 we should add a dedicated Documentation issue.
These settings are very unclear and have huge potential for hidden issues with different payment methods.
Users should be guided, which setting should be used for what!
@grevil can you do that maybe? Any maintainers should please assist with their knowledge
Comment #15
agoradesign commentedafter updating from 2.1.0 to 2.1.1, I see a "Mismatched entity and/or field definitions" error on status report page, the "Link email" field must be installed
Comment #16
agoradesign commentedaaaaaaa maybe because I was already patching PayPal before