[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!