Changes:
1. Webhook support:
a. Admins will be presented with the list of supported events for recurring. they can select which events to listen to and submit the form to create the webhook.
b. onNotify support for the following events
- recurring.agreement-stopped.v1
- recurring.charge-reserved.v1
- recurring.charge-captured.v1'
- recurring.charge-failed.v1
c. A new event VippsMobilePayEvents::RECURRING_STOPPED to support suspending the subscriptions instead of cancelling them. This allows the module to be compatible with the commerce_recurring suspend patch
2. Replace $matching_payments lookup in onReturn to be based on $charge_reference instead of $agreement_reference.
3. $payment->getRemoteId() in createPayment() is always null for recurring orders. I added the chainReferenceResolver as a fallback.
4. Added the order id as an external id for the agreement and removed unused $plugin variable in RecurringLandingPageRedirectForm.
There's still room for improvement any feedback is welcome.
mhawwari → made their first commit to this issue’s fork.
mhawwari → changed the visibility of the branch 3443980-cover-more-stripe-hard-decline-codes to active.
mhawwari → changed the visibility of the branch 3443980-cover-more-stripe-hard-decline-codes to hidden.
mhawwari → created an issue.
mhawwari → changed the visibility of the branch 3444153-isexpired-aborts-payments to active.
mhawwari → changed the visibility of the branch 3444153-isexpired-aborts-payments to hidden.
mhawwari → created an issue.
Some of these codes should display a generic message so I used the same message as DeclineExeption for all of them.
mhawwari → created an issue.
mhawwari → created an issue.
Closing this as the issue was fixed in #3139274
@floretan thank you for the prompt response!
I would like to become a maintainer on this project because it is provides a crucial functionality in several large projects we are working on and need to have drupal10 support for.
The MR is now always sending ALLOW and resulting in caching requests when it should not.
instead, I updated the request to only return a result when needed.
mhawwari → made their first commit to this issue’s fork.
Patch merged. Thanks
I understand this is not the conventional use of SupportsNotificationsInterface so the question here would be if SupportsNotificationsInterface should be allowed to be implemented separately from offsitePaymentGatewayInterface if it provides an endpoint that can be utilized with gateway webhooks. Or should a payment gateway always be considered an offsite gateway to integrate notifications.
The reason being that for non offsite gateways, you technically remain on the site, and completing checkout should place the order.
In our specific case, we have a new payment gateway that inherits the stripe onsite payment gateway to create intents and handle the checkout process as an onsite payment with the addition of an onNotify() method to listen to a webhook for the payment resolution from stripe to complete/cancel the payment since it takes a few days to be confirmed.
It is possible to make this into an offsitePaymentGateway but there will be no need for any of the methods that the interface provides.
mhawwari → created an issue.
mhawwari → created an issue.
mhawwari → created an issue.
mhawwari → created an issue.
I am getting this same error. This error is happening after calling load($id) from ConvertBundles.php in addNewFields():242
$entity = \Drupal::entityTypeManager()->getStorage($entity_type)->load($id);
The error is thrown on the bellow code because the $bundle variable is equal to the old bundle while the bundle key in the $definitions variable is equal to the new bundle. for our example we are converting from bundle default to bundle campaign.
if ($langcode == LanguageInterface::LANGCODE_DEFAULT || $definitions[$bundle][$field_name]->isTranslatable()) {
The values here are:
$definitions = [
'campaign' => [...],
]
while
$bundle = 'default'
Added a missing use statement from the previous patch
Added a temporary patch to be applied on top of #2 and the MR in #3341217: Add a way to include more info sent to stripe → to support PaymentIntentEvent in recurring calls as well
Sorry about all the new commits I finally got a chance to test the code properly and the code should be ready now
Added a new event similar to what's in this issue #3170903: Allow customising the payment intent → in commerce_stripe
I guess we can pass an empty intent array to only update attributes added from the event subscriber and that can avoid updating all the intent attributes in createPayment() after payment save. So we can pass new PaymentIntentEvent($order, [], $payment) to replace new TransactionDataEvent($payment).
Needed to use this patch for adding an intent description.
I applied the approach in #17 and added a new addIntentAttributes() method. I also just added a @deprecated tag for #16
The only concern here is if we should dispatch the event in the same place the transaction data event is being dispatched in the createPayment() method and pass the payment object if a project needed to pass info about the drupal payment to stripe.
mhawwari → created an issue.