fix(ras-acc): remove check to prevent credit card field reset

[laurelfulford]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

This check was originally added as part of #3330; my best guess is that additional changes have made this check unnecessary, but I could just be missing a certain case!

Note: There's a similar issue with apply a coupon after filling in the credit card information first, so this could be related in general to the use of update_checkout somehow. I'm still trying to puzzle that one out, but it's a much less likely order to have filled the form out in.

See: 1207817176293825-as-1208255803261156

How to test the changes in this Pull Request:

1. Set up Stripe Gateway and at least one other payment processor (like WooPayments) under WooCommerce > Settings > Payments. Order them so Stripe is not the default (it should be at the bottom of the list)
2. Enable "Allow donors to cover transaction fees" under Newspack > Reader Revenue > Stripe Settings, but don't have it preselected.
3. On the epic/ras-acc branch as a new, not registered reader, make a One Time donation.
4. On the second screen, switch to Stripe to pay.
5. Fill in your credit card information, then check the box to cover the fees.
6. When the modal updates, the Transaction Details table will be there, but the credit card information will have been cleared.
7. Apply this PR.
8. In a new incognito window, repeat steps 3-6, and confirm that the credit card information remains in place.
9. Retest some of the steps from the original issue this fixed (from the corresponding Blocks PR) to confirm nothing has regressed:
   a. As a new reader with no saved billing details/payment information, trigger modal checkout via any donation block (recurring donation to guarantee the transaction details table appears)
   b. Proceed through the checkout flow until you get to the payment information step. Scroll down to see the Transactions details table.
   c. Confirm that it's not greyed out (blocked).
   d. Smoke test the checkout modal in various other contexts (checkout buttons with tax/shipping/coupons/nyp/etc. setup, one-time donations, etc.)

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

[laurelfulford]

Switching this one back to draft for further investigation -- I noticed that this only happens when you're signing up as part of the transaction, if you're already logged in, or if you log in during the transaction, this doesn't happen 😕

[laurelfulford]

The NYP/coupon issues were wholly unrelated to this and have a fix here: Automattic/newspack-blocks#1881

I'm not sure if this is the right approach to fix this specific issue, but marking as ready for review again to get some eyes on it!

[chickenn00dle]

Good catch @laurelfulford!

This was part of my initial attempt to fix the transaction table from ending up in a blocked state. I later added Automattic/newspack-blocks#1875 as a more reliable solutions, but completely forgot about this bit.

Looks good on my end 👍

[laurelfulford]

Thanks @chickenn00dle! 🙌