[Bug] Error on submit credit card payment not logged by callbacks

[subvertallchris]

Library used

react-paypal-js

🐞 Describe the Bug

We are receiving intermittent reports from multiple users (including myself and another team member) of card rejections when using the "Debit or Credit Card" form in our checkout page. This presents as a generic error in the UI and offers no steps for recovery beyond trying a different card. We don't see this in our logs and the error callback is not triggered. As a result, we are losing an indeterminate number of sales and it is very disturbing.

We have reason to believe this is a restriction of the Guest Checkout feature. I'll post snippets of GraphQL logs from the browser below.

🔬 Minimal Reproduction

We are unable to reproduce this in our Sandbox environment! We see it frequently in prod.

This seems to happen more consistently with Mobile Safari on iOS.

😕 Actual Behavior

The user who is ready to pay presses the "Debit or Credit Card" option on the checkout page.
They enter their billing information.
In the background, the iframe makes a GraphQL query and gets a response like this:

{
    "errors": [
        {
            "data": [
                {
                    "field": "cardNumber",
                    "code": "CARD_GENERIC_ERROR"
                }
            ],
            "message": "R_ERROR",
            "path": [
                "approveGuestPaymentWithCreditCard"
            ],
            "extensions": {
                "class": "ERROR"
            },
            "checkpoints": [
                "addCard"
            ],
            "meta": {},
            "contingency": true,
            "statusCode": 200
        }
    ],
    "data": {
        "approveGuestPaymentWithCreditCard": null
    },
    "extensions": {
        "tracing": {
            "version": 1,
            "startTime": "2024-12-18T16:45:00.542Z",
            "endTime": "2024-12-18T16:45:01.916Z",
            "duration": 1373662639,
            "execution": {
                "resolvers": [
                    {
                        "path": [
                            "approveGuestPaymentWithCreditCard"
                        ],
                        "parentType": "Mutation",
                        "fieldName": "approveGuestPaymentWithCreditCard",
                        "returnType": "CheckoutSession",
                        "startOffset": 1367156,
                        "duration": 1372079809
                    }
                ]
            }
        },
        "correlationId": "REDACTED"
    }
}

They see this error on the page:

The error is inside of the payment information iframe. It's in a nondescript div, the only identifying information is a class of the error Icon, css-d8qyhy-ErrorSVGContainer e1m1vp830 -- that ErrorSVGContainer hints at it.

🤔 Expected Behavior

We'd expect a number of things:

• Ideally the error doesn't occur (seems beyond the responsibilities of this library)
• If it is a Guest Checkout limitation, it should identify itself as such and tell them to use a different payment method. It looks like many (all?) of the retryable card errors are capable of opening a Checkout modal that provides a different path.
• If it can't open its own modal that prompts for a retry, it should trigger our application's error handling callback so we can try to trigger the restart() method.
• If we can't force it to retry via different path we must be able to log errors so we have some insight into how many sales we are losing over this.

🌍 Environment

• Node.js/npm: - 20.10.0
• OS: - All
• Browser: - Chrome (Mac OS) and Mobile Safari iOS 17+

➕ Additional Context

We use the Multiparty/Commerce Platform APIs. I can provide a partner ID if it helps.

This is extremely high priority for us, our merchants are losing sales and we are very concerned about our inability to record and respond to these.

[wsbrunson]

hey @subvertallchris thank you for submitting an issue! I'm going to forward this to our internal checkout team to take a look

[subvertallchris]

Hey @wsbrunson thank you very much, this is causing a lot of people a lot of stress right now so I'm open to anything I can do to help move it along!

[wsbrunson]

I'm guessing they won't reach out directly on this ticket so I'll keep you updated and let you know if we need anything. If you do have a debug id/correlation id for the failed request I can send that along

[subvertallchris]

I do have a correlation id from a recent error, is that safe to publish here or should I send through some private channel?

[wsbrunson]

yeah its safe to put here thank you for checking though

[subvertallchris]

Got it, here you go: f798459c36ed1

Thank you!

[wsbrunson]

was this very recent like in. the last hour?

[subvertallchris]

No, it was within 5 minutes of 11:46 AM EST. I can get you a new one if you want?

[subvertallchris]

Fresh out the oven: f990206458a40
It's the result of a POST to /graphql?fetch_credit_form_submit

[wsbrunson]

oh sorry, i meant was the issue itself recent. There was a potential overlap with a deploy but the team ruled that out already

[subvertallchris]

Oh I see. No, this has been ongoing intermittently for many weeks. We realized we had a bigger problem about 2 weeks ago when I opened the case with Merchant Support.

[subvertallchris]

Hey, don't suppose there's any movement here? Specific transactions aside, an error that can't be tracked to determine the scale and can't offer the buyer any help at all is really a problem. I understand if it's outside the domain of this repo since the GraphQL query, response handling, and error presentation live entirely within the closed source script, but is there anything that can be done?

[wsbrunson]

hey @subvertallchris sorry for the long silence, myself and the guest checkout team have been on and off for the holidays. I have an update though.

The team is aligned on sending these types of errors through the onError callback. There was discussion on how we could recover from an error like this and present checkout but the major problem is that at the time of the error, we no longer have the context of a user action and so opening our checkout window would be blocked.

I can't comment on when they'll have this implemented but they do agree that it is a missing feature and they are currently working with our product team as far as prioritization

[subvertallchris]

Ahhh @wsbrunson, this is like a late Christmas gift... Thank you! Being able to even record occurrences of the error will be a huge improvement.

Where chats about prioritization are concerned, hopefully the product team understands that it's essentially invisible since nobody's code can even log the error occurring. A lack of reports to PayPal is surely influenced by this since developers only know when someone reports it and buyers on e-commerce sites are unlikely to do that. I see evidence that it's been happening for years across numerous sites (a lot of Discogs users have posted about it) but I think it's just not on most devs' radars since it can't be tracked or reproduced.

[wsbrunson]

Thank you @subvertallchris I will forward your message directly to them!

[subvertallchris]

Thank you so much @wsbrunson! Made my day. This has been a major source of anxiety for us, the team and our users really appreciate it.

[UtopieStudio]

Is there any movement on this with Apple Safari users?
We are getting a number of complaints a week now with users affected and losing sales.

I looked at the subscriptions checkout where you supply the id of the subscription item manually set up in PayPal account.
When used with a subscription item, the Credit Card button seems to open the input form in a pop-up instead of animate-reveal in-line on the page.

It would be so much easier if you could enable this same pop-up credit card form as an option for one-time purchase payments too, avoiding all these i-frame and security bugs with namely Safari users.

We don't even have the option of a hosted payment page with PayPal now, as you might with a provider like Stripe for example.

At the minute it feels like users, shop owners and PayPal are all missing out on what would be collectively, substantial sales revenue and fees.

It seems like it has existed for an unreasonable amount of time now without being fixed.

Considering the massive presence of PayPal as a payment provider and the amount of Apple and Safari users out there, this is a huge disappointment.

[wsbrunson]

Considering the massive presence of PayPal as a payment provider and the amount of Apple and Safari users out there, this is a huge disappointment.

hey @UtopieStudio are you saying that you see issues with the inline payment fields on Apple Safari? Like they don't load or error out for reasons other than the card details not being correct/declined?

[UtopieStudio]

Considering the massive presence of PayPal as a payment provider and the amount of Apple and Safari users out there, this is a huge disappointment.

hey @UtopieStudio are you saying that you see issues with the inline payment fields on Apple Safari? Like they don't load or error out for reasons other than the card details not being correct/declined?

Greetings @wsbrunson. It's hard to pin down exactly what individual users are experiencing. A commonality is we are contacted by someone often with an icloud email address stating they can't pay, they've tried 2 cards etc.

I look at the PayPal dev backend logs, and there's no errors, but I can see the user with the payment issue just making constant CAPTURE requests - I can't recall now if it was 200 or 201.

Experience told me it is probably something to do with the in-line form, and after some research, this is what other people seem to be experiencing too; weather that's iframe, js script blocking issues or something else, I've honestly no idea.

To me it just seems like the best solution is to have the ability to switch the in-line form to the pop-up window version (as happens with subscription Credit Card button presses) while these issues are tracked down and ironed out.