Hi @luiscordeiro,
I’m glad you’re liking the plugin. In WC if a payment for an order fails, you will also have a shop_order post type. That is part of the core WC behavior regardless of whether it’s a subscription or not.
The bfwc_subscription post type contains metadata about the subscription such as renewal date, price, products etc. WC and this plugin require that in order to accurately perform calculations etc. That data is also required at the time the Braintree plugin processes the transaction and creates the subscriptions in Braintree.
It is not until the payment is successful that the bfwc_subscription post status is updated to active.
Kind Regards,
Thread Starter
Luis
(@luiscordeiro)
Thanks for the quick reply.
Shouldn’t the subscription just be created in BrainTree if the shop_order is successful?
We are having some use cases where a client does this:
- Places the first order but it failed (refused credit card for example)
- Places a second order and succeeds
This creates 2 (pending) subscriptions for that client.
One for the failed payment.
One for the success payment.
And we have to go to BT to manually cancel the subscription from the first failed order.
Do you see any reason for having the first subscription be created, because we never receive any payment from the customer (and when the renewal comes it will also fail).
Thanks again for your help!
Hi @luiscordeiro,
Thanks for providing more details. Here is how the plugin works:
1. Subscription is created in Braintree first because the payment method must be saved since a payment nonce can only be used once. Therefore, first step is to save payment method, then saved payment method is used to create subscription in Braintree.
2. Once subscription is created in Braintree, postmeta is updated to show subscription is created.
3. If the subscription starts immediately, then transaction using saved card number is processed. If the transaction fails, then message is shown on checkout page.
4. Customer then corrects card info and re-submits. If subscription has already been created, then that part is skipped and transaction portion is called.
So you shouldn’t be seeing multiple subscriptions in Braintree. Your original request made it seem like you only saw multiple post types of bfwc_subscription which is normal.
It’s weird that the payment method would save no problem but then the same payment method would fail while processing the transaction. The subscription is only created in Braintree once the payment method is saved and saving a card requires that same info as charging a card for the most part.
Kind Regards,
Thread Starter
Luis
(@luiscordeiro)
Hi @mrclayton thanks again for the explanation details.
That behavior makes sense (not duplicating subscriptions on a failed payment).
I believe we may have problems with webhooks, because we are not receiving any events from BrainTree (although we have the correct url and events setup in BT). This could maybe explain the duplication of subscriptions on failed payments.
For example:
– If we cancel a subscription in BT, the WooCommerce subscription remains Active. But if we cancel in Woo then it’s cancelled in BT.
I’ve checked the logs but it only logs the transaction from Woo to BT.
Is there a way to see any logs for the webhooks ?
Thanks again for you help!
Hi @luiscordeiro,
The plugin is coded to only cancel the Braintree Subscription in the Braintree dashboard if it’s cancelled in WC. The idea there is that the merchant will be managing the subscription from WC making it the system of record.
You can perform a webhook test within the Braintree control panel on the webhook creation page. An entry will be added to the log if the webhook is received.
Kind Regards,
Thread Starter
Luis
(@luiscordeiro)
Hi @mrclayton, thanks.
I’ve done a few tests with the webhooks and we were able to have the webhooks being triggered after adding these lines to the ‘process_webhook’ function.
After this, if we cancel a BT subscription (in BT account) the subscription in Woo was updated to Cancelled too.
It’s seems the wc_braintree_notification parameter was not sending any values. Only by parsing the signature and payload, was I able to get the notification object.
Is it possible BrainTree changed something on the webhooks args?
Here’s the code I’ve added.
$notification = $request->get_param( 'wc_braintree_notification' );
// FIX START
$bt_signature = $request->get_param( 'bt_signature' );
$bt_payload = $request->get_param( 'bt_payload' );
$notification = braintree()->gateway()->webhookNotification()->parse(
$bt_signature, $bt_payload
);
// FIX END
try {
// developers can use this hook to process webhooks to suite business needs.
do_action( 'wc_braintree_webhook_notification_' . $notification->kind, $notification, $request );
Thanks!
-
This reply was modified 3 years, 9 months ago by
Luis.
-
This reply was modified 3 years, 9 months ago by Luis.
Hi @luiscordeiro,
I just ran a test and the webhooks worked as expected. The plugin already parses the payload and signature before the notification is passed down to the webhook controller. Here is the code:
https://docs.paymentplugins.com/wc-braintree/api/source-class-WC_Braintree_Rest_Webook_Authentication.html#38
Kind Regards,
Hi @luiscordeiro,
I have figured out what the issue is. In WP a check for trailing slashes was added in the REST API and as a result, the authentication route looks like wc-braintree/v1/webhooknotification instead of wc-braintree/v1/webhook/notification.
That causes the step which populates the notification object in the request to be skipped. That’s why your customer piece of code fixed it. I have made a note to include a fix for this in the next release.
Kind Regards,
Hi @luiscordeiro,
Version 3.2.15 released which resolves the 404 webhook check.
Kind Regards,
Thread Starter
Luis
(@luiscordeiro)
Hi @mrclayton thanks for fixing so quickly!
