customerPaymentMethodRemoteCreate is returning brand: bogus but sometimes creating payment methods

[simplee_chris]

Hello,

We're running migrations and using the new customerPaymentMethodRemoteCreate to migrate from Stripe. Our team is finding that the response from this mutation is consistently returning bogus payment method information. The annoying part is that sometimes it seems like Shopify is actually creating a payment method successfully, and othertimes it isn't.

Sample query:

mutation customerPaymentMethodRemoteCreate($customerId: ID!, $remoteReference: CustomerPaymentMethodRemoteInput!) {
  customerPaymentMethodRemoteCreate(customerId: $customerId, remoteReference: $remoteReference) {
    customerPaymentMethod {
      id
      instrument {
        ... on CustomerCreditCard {
              firstDigits
              source
              brand
              name
              virtualLastDigits
              maskedNumber
              lastDigits
              expiryYear
              expiryMonth
        }
      }
    }
    userErrors {
      field
      message
    }
  }
}

with variables:

{
  "customerId": "gid://shopify/Customer/XXXXXXXXXXXX",
  "remoteReference": {
    "stripePaymentMethod": {
      "customerId": "cus_xxxxxxxxxxx"
    }
  }
}

and the reply is:

"data": {
        "customerPaymentMethodRemoteCreate": {
            "customerPaymentMethod": {
                "id": "gid://shopify/CustomerPaymentMethod/941506c7e5ce69537481efXXXX",
                "instrument": {
                    "firstDigits": "",
                    "source": "remote",
                    "brand": "bogus",
                    "name": "",
                    "virtualLastDigits": null,
                    "maskedNumber": "•••• •••• •••• ••••",
                    "lastDigits": "",
                    "expiryYear": 1900,
                    "expiryMonth": 1
                }
            },
            "userErrors": []
        }
    }

but then if I query the customer, a payment method with the same CustomerPaymentMethod has sometimes been created successfully, and sometimes not.

Can anybody confirm issues with this recently? It's incredibly frustrating.

Chris

[qc11]

Hi,

Just trying to understand the problem better - is `customerPaymentMethodRemoteCreate` mutation returning `brand: Bogus` even if the card is other brand? Or you are expecting the mutation to always fail with Bogus card but it didn't sometimes.

[simplee_chris]

We did a bunch of testing yesterday, and every call to customerPaymentMethodRemoteCreate is returning bogus information. This includes an expiry year of 1900, empty last digits, etc.. even though it appears to be successfully creating a payment method.

When we query the customer for payment methods, the same paymentMethodId is displayed with the correct brand, expiry, last digits, etc...

It seems like the initial call to create the payment method isn't returning real values.

Let me know if I can do anything to show you exactly what I mean, but you can use the example queries I provided with a valid Stripe customer ID.

[qc11]

Would you mind also send me the shop id you are testing via private message so I can investigate further?

[Raven6]

Hello, I have the same problem. 
When I use CustomerPaymentMethodRemoteCreate it returns bogus data. 
And when i Query the Customer it return empty array on the Payment Method. 

Do you already have fix for this ? Thanks !

[Brian_S · Accepted solution]

@simplee_chris This is because the process is async. You have to build in a retry process to pull the returned customer payment method. Assuming the Stripe input is correct and Stripe is connected, eventually it will return a payment method with all the correct data. Generally it's fairly immediate but it's never on the initial creation call because there are async processes that need to occur.  The fact that it returns the bogus data is confusing for sure.. a "processing" state would be better because if the stripe data was incorrect or the payment method could not be created it is very hard to tell the difference between that processing state and the fact that it just didn't work. I've found that if you try to pull it a few times with a little backoff and you still end up with bogus data, that means it did not work. 

[simplee_chris]

Thanks Brian, I appreciate your insights.

This makes sense for sure. I know that when we've run migrations in the past, this was never an issue and the results have been instant.

Agreed that there needs to be a better indication of the actual status of the request, similar to billing attempts. We should never get bogus data back, but a status message instead.

We've adjusted our migration script in the meantime, but I'd suggest an update to the documentation which describes how to migrate payment information.

[qc11]

@Brian_S Thanks a lot for stepping in! I'm definitely not familiar with this area.

And as @simplee_chris  suggested, I will look into make an update on our documentation to clarify the process.