Payment is processed but server error is returned if user misenters Zip Code

[johngruen]

Last of the killer payment form errors, i Hope...

Right now, if i pay and mis-enter my zip code, my payment is processed by the frontend fails and I see the auth error, pictured below...If the user's zip is misentered, we should show the card_error dialog instead of failing on the front end while subscribing a user on the back end.

Related to #3106

[lmorchard]

Having trouble reproducing this on my local dev stack. I've got FxA and a docker container with subhub running on my machine. Subhub is pointed at my personal Stripe account with "Postal code verification fails" rule turned on in Radar to decline payment.

When I use a test card that triggers zip code errors (i.e. 4000 0000 0000 0036) I get this error dialog, which looks correct:

But the screen cap in the description of the issue says "Problem loading customer information" and "backend service failed"

This suggests to me that there was a 500 internal service error response from subhub while fetching the customer info. But, that's happening well after the request to create a subscription, while trying to refresh customer info to show changes.

I think we need to dig through some server logs to see if we can find any 500 errors on the FxA or subhub sides related to this issue.

[lmorchard]

@johngruen In what environment did you see this error? Need some more info to track it down I think - e.g. what account, when did it happen, etc. I don't think is a simple case of displaying the wrong error message in payments-server

[lmorchard]

Also, I tried to reproduce this on stage, but didn't even get an error for the invalid zip code. Do we have the Stripe Radar rule enabled there to reject bad zip codes?

Edit: Just remembered I think I have access to Stripe for staging, and the rule is disabled there:

(I don't personally have access to prod Stripe, so I can't check there)

[lmorchard]

I'm not sure if this is the culprit, but I found what I think is a typo in subhub (charge vs customer) that could be causing an issue if the payment status is incomplete for this subscription:

mozilla/subhub#332

If the zip code mismatch wasn't caught on the subscription creation stage, could be that this bug gets exercised by the payment that didn't succeed yet wasn't rejected on submission? I'm fuzzy on how stripe behaves here

[johngruen]

@lmorchard i did this in prod where we do have zip code erroring on...

So If i go to Radar on prod i see that the Zip Check failed

But somehow the payment still went through?

[lmorchard]

But somehow the payment still went through?

I don't think the subhub issue I found would cause that, but then I'm not sure what would. I don't think it's from the fxa side of things, though

[stlhood]

@marty331 has a fix for #332 which should fix this, will go out by Thursday.

[marty331]

@johngruen @lmorchard PR for subhub #332 has been pushed to prod and prod-test.

[lmorchard]

We probably want to re-test this issue before closing. I wasn't quite able to reproduce as described. When I was deleting subscriptions in my local database after deleting them from Stripe, I ran into subhub's #332 - which looked like the screenshot in the issue description. But, I can't definitely say whether it was the cause of this issue.

[johngruen]

So the results here have changed here somewhat...Now, the payment will successfully submit with a misentered ZIP. We need to resolve this to launch b/c it goes to export control.

[marty331]

In the stage environment in Stripe Radar the "Block if Postal Code verification fails" rule was NOT enabled and I was able to successfully subscribe to a plan with a CC that fails zip code verification. Next I enabled "Block if Postcal code verification fails" and tried again with the same test card and it is no longer accepted. I believe this is the behavior we want and therefore recommend enabling this in the production account as well - I have not touched the production Stripe account. Also, no code changes were needed from the SubHub side.

After "Block if Postal code verification fails" was enabled for the production Stripe account I created an account and used a live credit card and successfully received a declined message.

[johngruen]

This has been resolved fixed in prod by @marty331 who was able to test the fix.