Joe

Yes of course. Great updates overall! The short description is finally working

Just adding my error log as well if that helps…

Fatal error: Uncaught Error: Cannot use object of type stdClass as array in /var/www/parisbloom.com/html/wp-content/plugins/wp-fail2ban/vendor/freemius/wordpress-sdk/includes/managers/class-fs-key-value-storage.php:154 Stack trace: #0 /var/www/parisbloom.com/html/wp-content/plugins/wp-fail2ban/vendor/freemius/wordpress-sdk/includes/managers/class-fs-key-value-storage.php(129): FS_Key_Value_Storage->load() #1 /var/www/parisbloom.com/html/wp-content/plugins/wp-fail2ban/vendor/freemius/wordpress-sdk/includes/managers/class-fs-key-value-storage.php(107): FS_Key_Value_Storage->__construct('admin_notices', 'global', 0) #2 /var/www/parisbloom.com/html/wp-content/plugins/wp-fail2ban/vendor/freemius/wordpress-sdk/includes/managers/class-fs-admin-notice-manager.php(123): FS_Key_Value_Storage::instance('admin_notices', 'global', 0) #3 /var/www/parisbloom.com/html/wp-content/plugins/wp-fail2ban/vendor/freemius/wordpress-sdk/includes/managers/class-fs-admin-notice-manager.php(93): FS_Admin_Notice_Manager->__construct('global', '', '', in /var/www/parisbloom.com/html/wp-content/plugins/wp-fail2ban/vendor/freemius/wordpress-sdk/includes/managers/class-fs-key-value-storage.php on line 154

Fixed with this filter, run on wp_loaded

add_filter( 'wc_braintree_localized_paypal_params', function($data) {
	$data['options']['intent'] = 'authorize';
	return $data;
});

Woocommerce: Order authorized in Braintree: Transaction ID: ********. Payment method: American Express ending in ****

Braintree Authorized!

So yes, it is an issue of CC vs PayPal Gateways.

My intent is to use the PayPal gateway because I can have an authorization that lasts up to 29 days versus credit cards that are only good for 3 days (Amex) up to 2 weeks (others). So it’d be great to figure this out!

That’s what was confusing to me.

In Woocommerce the order note says: Order authorized in Braintree: Transaction ID: ********. Payment method: PayPal – *********@gmail.com

In Braintree and in PayPal, the payment is authorized, submitted for settlement, and settled all at the same time.

• This reply was modified 5 years, 2 months ago by Joe.

Oh I guess I misunderstood the filter. It’s not enough to just add a filter? I already have an action that runs on wp_loaded that runs a bunch of other filters if this product is in the cart, so I’d prefer to simply set it there.

add_filter( ‘wc_braintree_transaction_submit_for_settlement’, ‘__return_false’ );

From my quick look at the code, it looks like if get_option is ‘capture’, it’s just setting that filter to true. So if I set to false it should authorize?

I tested it with PayPal, and it says authorized in the order notes, but it still captured the payment in PayPal.

I swear I searched for that!

Sorry for wasting your time, but thank you for the quick response.

Fantastic, thank you!

Awesome, thanks for tracking that down. I thought that was what was happening but am not experienced enough to find it myself!

Great, thank you!

Just curious, what was the issue?

Zorem,

Thank you for your work on this. I am using the same ShipStation integration.

It seems that my ShipStation is returning ‘USPS’ (uppercase) as the carrier. When this is inserted into the order meta, it does not match to USPS in the plugin, which enters it as lowercase (I believe… it might be the reverse).

Now, with the code above, I could simply add strtolower to the carrier, but I’m sure that would lead to issues with other carriers.

What do you think is the best way to go about this?

Edit: Actually, looks like your plugin expects lowercase, it’s being entered in uppercase from ShipStation

• This reply was modified 5 years, 3 months ago by Joe.
• This reply was modified 5 years, 3 months ago by Joe.

Fantastic explanation, thank you!

Joris, the shop is currently behind a login only during pre-orders for our customers.

If you don’t mind creating a login, you can see it at https://parisbloom.com/shop/

No rush! Enjoy your vacation…

I’ll try to troubleshoot and post some thoughts here in the meantime. It’s not a site-breaking bug, and I have so much going on on my store it could very well be an incompatibility with something else.

Here’s the cookie info after adding one product: https://imgur.com/3YRijmj
After adding two: https://imgur.com/UCIc9eD

When removing a product, the cookie goes back to one id just fine, but when trying to remove the last product, it stays until the second time visiting the page and removing again.

And in the user meta, the value goes from:

a:1:{i:0;s:4:"5841";}
to
a:2:{i:0;s:4:"5841";i:1;s:4:"4915";}

It is a cookie issue, although I’m not quite sure how yet.

After removing the last item, the cookie still has the last product id in it, even though the user_meta wishlist key goes to value:
a:0:{}

Looking into it further.

• This reply was modified 5 years, 4 months ago by Joe.
• This reply was modified 5 years, 4 months ago by Joe.
• This reply was modified 5 years, 4 months ago by Joe.
• This reply was modified 5 years, 4 months ago by Joe.

The problem resolved itself after deleting all plugin data and starting over.

Sorry for wasting any of your time!