Closed zackspear closed 2 years ago
We had this happen again but with slightly different circumstances.
User chose USA as the country but then didn't select a state. Upon first payment submission they received an error of
US state codes must be two characters to meet PayPal Seller Protection requirements.
They went back and corrected that. Then attempted payment again. Which resulted in the same error as detailed above in the issue description.
Impossible to access an attribute ("paymentInstrumentType") on a null variable.
I went ahead and added validation for both the postal codes & now state selection to help prevent this. But ultimately seems like something is going wrong when first payment attempt somehow fails.
Hi @zackspear, sorry for the delay in looking into this. I can see the successful transaction response above has the paymentInstrumentType
attribute. How are you accessing the paymentInstrumentType
in your email template?
In your email template have you tried add some defensive code to ensure the paymentInstrumentType
attribute exists as this could be causing the error on the site.
Closing this due to age.
Recently we received a support request from a customer claiming to be double charged. I was able to figure out how it happened to them.
If the user enters a postal code with invalid characters like
12345-____
, they can proceed to payment and submit payment via the Drop-in UI (I realize I need to build in validation to prevent users from progressing to the next checkout step).First attempt with invalid postal code results in this, which should be expected. Not sure why the error message is tripled. Here's the gateway response from the transaction details
After going back to the user info form and correcting the postal code then coming back to the payment form, upon submission the form responds with this error:
Now from the user's perspective the transaction failed. However, looking at the order details in the CMS & in Braintree, this attempt succeeds.
Gateway response for the success. Seems to be missing some information.
This failure also results in our order email failing as the custom template relies on
paymentInstrumentType
to display the payment type of CC or PayPayl. Job data from failed emailI plan to build in validation to prevent postal code issues in the first place. However, I wanted to bring attention to the fact that even with a correction to the postal code we're hitting this issue.
If you need more information please let me know.
Thanks in advance.