FROM CACHE - en_header

Stripe payment method from customerPaymentMethodRemoteCreate fails during billing

Solved
vladimird
Tourist
8 2 6

Dear colleagues,

We migrate subscriptions from an external system to Subscription API. Following the subscription migration guide, we create payment methods for Stripe as described here: https://shopify.dev/apps/subscriptions/migrate/contracts#create-new-payment-methods-for-the-customer

For each customer we know: their Shopify ID ("gid://shopify/Customer/xxx"), their Stripe ID ("cus_yyy") and we can get their Stripe payment method ID ("card_zzz").

As described in the documentation, we use GraphQL mutation customerPaymentMethodRemoteCreate to create payment methods from this data. During this summer this approach was working successfully with GraphQL (API version 2021-07). We were making a call to the mutation like this and didn't even need the optional payment method ID:

 

 

 

mutation {
  customerPaymentMethodRemoteCreditCardCreate(
    customerId: "gid://shopify/Customer/xxx"
    stripeCustomerId: "cus_yyy"
  ) {
    customerPaymentMethod {
      id
    }
    userErrors {
      field
      message
    }
  }
}

 

 

 

 

Around September 23/24 this mutation call stopped working, and it started failing with an error:

 

 

 

  "customerPaymentMethodRemoteCreditCardCreate": {
      "customerPaymentMethod": null,
      "userErrors": [
        {
          "field": [
            "stripeCustomerId"
          ],
          "message": "Payment instrument stripe customer can't be blank",
          "__typename": "CustomerPaymentMethodUserError"
        }
      ],
      "__typename": "CustomerPaymentMethodRemoteCreditCardCreatePayload"
    }

 

 

 

 

The error looks strange, as we DO pass stripeCustomerId we just don't pass stripePaymentMethodId. And yet the error complains about stripeCustomerId.

We tried to change our call and added parameter of Stripe payment method ID:

 

 

 

mutation {
  customerPaymentMethodRemoteCreditCardCreate(
    customerId: "gid://shopify/Customer/xxx"
    stripeCustomerId: "cus_yyy"
    stripePaymentMethodId: "card_zzz"
  ) {
    customerPaymentMethod {
      id
    }
    userErrors {
      field
      message
    }
  }
}

 

 

 

With this addition the mutation worked - at least, it didn't fail with error and it created a payment method. But when we tried to create a billing attempt on a subscription that is associated with this payment method we received an error: "No such customer: 'card_zzz'". The error came from Shopify payment failed webhook, not from billing attempt call. Please, note that it tried to use Stripe payment method ID as Stripe customer ID.

We tried then to switch to a new mutation (customerPaymentMethodRemoteCreate instead of customerPaymentMethodRemoteCreditCardCreate). But is has all the same problems:

If we call customerPaymentMethodRemoteCreate with just a remoteReference.stripePaymentMethod.customerId, it fails with error:

Internal error. Looks like something went wrong on our end.
Request ID: 96b6e0c3-ab0b-439b-8f52-645b6468c40d (include this in support requests).

If we call it with both remoteReference.stripePaymentMethod.customerId and remoteReference.stripePaymentMethod.paymentMethodId, then it creates a payment method, but subscription billing attempt fails with exactly same error: "No such customer: 'card_zzz'"

So, regardless of which mutation we use, the created payment method seems to put card ID in place of customer ID.

Please, address this ASAP as this makes entirely impossible to onboard new clients from external systems to Shopify.

Accepted Solution (1)

Accepted Solutions
vladimird
Tourist
8 2 6

This is an accepted solution.

We've received a reply from Justin B from Shopify Developer Support that this was fixed:

Just letting you know the issue was identified and a fix was just deployed. The fix has restored the previous behaviour for this mutation by allowing it to be sent with only the StripeCustomerId and customerId arguments. It will also ensure any payment methods created with this mutation moving forward are valid and able to process billing attempts.

View solution in original post

Reply 1 (1)
vladimird
Tourist
8 2 6

This is an accepted solution.

We've received a reply from Justin B from Shopify Developer Support that this was fixed:

Just letting you know the issue was identified and a fix was just deployed. The fix has restored the previous behaviour for this mutation by allowing it to be sent with only the StripeCustomerId and customerId arguments. It will also ensure any payment methods created with this mutation moving forward are valid and able to process billing attempts.