Smoky Barnable

In \includes\modules\shipping\usps.php I commented out the following in the $request variable. '<Country>' . tep_get_country_name($order->delivery['country']['id']) . '</Country>' . '<Container>RECTANGULAR</Container>' . '<Size>LARGE</Size>' . //'<Width>0.2</Width>' . //'<Length>0.2</Length>' . //'<Height>0.2</Height>' . '<Girth>0</Girth>' . '<OriginZip>' . SHIPPING_ORIGIN_ZIP . '</OriginZip>'

Pardon my ignorance, but isn't the whole point of having a "core" is so add-ons don't continuously have to be updated every time there is an update? Trying to wrap my head around why a Phoenix update would break so many free add-ons.

I have found using a file comparison utility quite helpful. My favorite is Beyond Compare. https://www.scootersoftware.com/

Removing the dimensions from the international API request has solved the issue for me. I am now getting first class international package quotes as expected.

Noticed today response is not returning 'First-Class Package International ServiceTM\'.

@raiwa Curious if this might work with webP images?

I do get the occasional duplicate payment, but it's quite rare.

Never mind. I'm pretty certain the USPS API is suffering intermittent service outages today. So, no charge when the API times out and no shipping quote is retrieved. https://www.shippingapimonitor.com/history.html?api=usps

Today I notice all my customers checking out using the PayPal Express method are not being charged shipping. Anyone else having this problem today?

Thinking of the idea of subscriptions/recurring billing as an option using the stripe api. Could perhaps be worked into this add-on. Thoughts? https://stripe.com/docs/billing/subscriptions/overview

GoDaddy possibly blocking IP's? https://www.paypal.com/us/smarthelp/article/what-are-the-ip-addresses-for-live-paypal-servers-ts1056

I think this was caused by a network communication/timeout error since it only happened once in thousands of orders, so I'm not too concerned with it. On another note, I was quite pleased when looking in my admin total revenue box that my sales had increased dramatically over the last few months. However it seemed too high....I realized today that the total revenue is not being reported correctly because it's treating orders with a status of Preparing [Stripe SCA] as completed purchases. These are customers that have not completed payment but are being counted as sales in the total revenue module. As a temporary solution, I patched the query to ignore orders with a status of "Preparing [Stripe SCA]". I also changed this in all code that generates sales reports. I don't know if there is a better solution, but this really skewed my perception of how my business was performing the last few months and as such is quite an important issue in my opinion. I do understand that this can be avoided by manually deleting incomplete orders but I don't consider this a viable solution. Moderator Comment Discussions regarding Order status split to the following thread as requested by Rainer.

Just had a strange issue. I received an order email, but when checking the admin there was no order. Stripe logs show the payment failed because "The PaymentIntent requires a payment method." I checked customer account and there are no items in the cart. Customer received order confirmation email but payment was not processed and order not created. View counter monitor logs show the following: checkout_success.php action=update 1 Sun, 1st 22:30:21 -> checkout_success.php 2 Sun, 1st 22:30:12 -> account_history.php 1 Sun, 1st 22:30:01 -> checkout_process.php 1 Sun, 1st 22:29:30 -> checkout_confirmation.php 1 Sun, 1st 22:24:55 -> checkout_payment.php 1 Sun, 1st 22:24:30

I thought this was a support thread for JcM Header/Footer message Add-on. What's up with all the irrelevant posts?

Turns out they don't support the Brave browser. Only the browsers listed here will function properly. https://stripe.com/docs/js/appendix/supported_browsers It would be nice to display a message to customers that aren't using a supported browser.