sukatoa-customers | Stripe Developers | Page 1

dire hemlock Jul 22, 2022, 11:24 AM

#

so to be clear, I have absolutely zero context on what this migration is or who you worked with or anything.

But sure, it's possible that when the migration was done, they imported cards from another payment processor as card_xxxx objects and then set those card_xxxs as the default_source on subscriptions. That is the legacy way to do things.

The way it works is that a subscription has a default_source and an invoice_settings[default_payment_method]. You can only set legacy card objects in the former. In the latter, you can set either a legacy card object or a current PaymentMethod pm_xxx, they both work.
When we try to charge a subscription, we look first at invoice_settings[default_payment_method] , if that's set, we charge that, and we only look at default_source if that's not set.

#

so in your case since your code(correctly) only really looks at invoice_settings[default_payment_method] , to me the solution is you should manually copy the value of default_source to invoice_settings[default_payment_method] in a migration so that your saved objects on your account are all consistent.

dire hemlock Jul 22, 2022, 11:26 AM

#

atomic patio Back to our unit test, it causes problem because the mechanism is looking for th...

yeah that doesn't work(setting a PaymentMethod pm_xxx to default_source). But the reverse (setting a card_xxx as an invoice_settings[default_payment_method]) does work.

atomic patio Jul 22, 2022, 11:28 AM

#

i see. Well, the live data (customer/PM) pair already generated, and to point out which default PM, it was set on default_source as card_XXX. We don't have problem with it so far.

The problem was on our unit test. How to mimic what the stripe engineers did on those customer/PM pairs, and have it as a test data for our migration mechanism to be tested

#

Example customerId Stripe engineers generated:

#

This is how the customer/PM created via unit test

dire hemlock Jul 22, 2022, 11:30 AM

#

How to mimic what the stripe engineers did on those customer/PM pairs, and have it as a test data for our migration mechanism to be tested
you'd have to use the legacy APIs like you said earlier

s I understand about cards, we can generate that only when we use Source Object – then attach that card to the Source object. Therefore when we attach the Source to the customer, the default source id should be ‘src_XXXXXXXXXX’ right? But wondering how did they come up with this id as card added as default Source. We initially avoid the Card Payments with Sources as it’s already deprecated

#

easiest way is like this really

let customer = await stripe.customers.create({
    email: "test@example.com",
   source: "tok_visa"
});

#

doing it that way adds a token(which becomes a legacy card_xxx object), and it also sets it as the legacy default_source field automatically

atomic patio Jul 22, 2022, 11:32 AM

#

I see, but the result will be, the default_source will contain "src_XXXX" and not "card_XXXX"

#

aahhhhh

dire hemlock Jul 22, 2022, 11:33 AM

#

atomic patio I see, but the result will be, the default_source will contain "src_XXXX" and no...

only if you use the v1/sources API. Use Tokens and Cards (see e.g. https://stripe.com/docs/api/cards/create) instead. default_source doesn't mean a capital-S Source, it's generic term for a payment source. There's unfortunately multiple legacy 'sources' that can be used there. I'd try to ignore them all really since only PaymentMethods matter.

atomic patio Jul 22, 2022, 11:36 AM

#

i see. Great info, can we save this convo, I will be AFK and get back to this later to review. is that okay not to archive this yet?

dire hemlock Jul 22, 2022, 11:56 AM

#

I'd suggest copy and pasting out of Discord somewhere

#

hi there! how can I help?

atomic patio Jul 22, 2022, 11:18 AM

#

Thanks for creating this thread

#

We need them to recreate the subscription given the customer/payment method pairs with reference in metadata how the stripe subscription be generated and attach to that customer object.

We are currently building a unit test on our migration mechanism, and one of them is to generate pairs of customer/payment method mimicking what the Stripe Engineers generated and let our mechanism do the recreation given the generated test data.

Then we encountered a problem.

We initially thought the way they(Stripe engineers) generate Customer and attach the payment method is straight forward like we do in programming.

#

When we create customer object and payment method then attach to each other, this is the result which works properly in production too -> test customer id: cus_M6W9RRseyushKr

You will notice that we directly attach the payment method as default payment method under invoice_settings.

#

#

And this is what the Stripe engineers generated. One of them is like this test customer object -> test customer id: cus_L4HaqfcyC22onT

You may notice that they set the default payment method in default_source and looks like it’s coming from a Card object, not via Payment Method standard procedure.

#

#

As I understand about cards, we can generate that only when we use Source Object – then attach that card to the Source object. Therefore when we attach the Source to the customer, the default source id should be ‘src_XXXXXXXXXX’ right? But wondering how did they come up with this id as card added as default Source. We initially avoid the Card Payments with Sources as it’s already deprecated

My reference:
https://stripe.com/docs/sources/cards
https://stripe.com/docs/api/cards

Card payments with Sources

Use Sources to accept card payments from around the world.

Stripe API reference – Cards – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

#

To my surprise, when we extract the payment method available within the customer cus_L4HaqfcyC22onT – this card id card_1KO91SHxUYbY7mq5Sszj79bR appears as the Payment method of that customer

#

Back to our unit test, it causes problem because the mechanism is looking for the default source in customer object. But the way we generate payment method and attach it to customer is via invoice_settings > default_payment_method. We tried to copy the payment method id and set it as default source, but it causes error like this:

customerId: cus_M6W9RRseyushKr
paymen method id: pm_1LOJ6lHxUYbY7mq5YHZl0oxV

dire hemlock Jul 22, 2022, 11:20 AM

#

who are "the Stripe engineers"?

atomic patio Jul 22, 2022, 11:20 AM

#

I get fascinated how the Stripe engineers did this attachment of card id “card_xxxx” style to into default source when they are in payment method.

Would you be able to help us know how to attach that payment method into default source? And maybe make its id with “card_xxxxx” as prefix if possible.

dire hemlock Jul 22, 2022, 11:21 AM

#

anyway you should ignore default_source

#

it's legacy

atomic patio Jul 22, 2022, 11:21 AM

#

The engineers from Stripe that our counterpart negotiate with on migration from Zeus payment system to stripe

#

oh it's legacy

#

hhhhmmmm

#

but, right now, they are using the default_source, embedded the card_XXX id, which is the payment method

#

our mechanism on migration was forced to look up on default_source

#

but when we create unit test, the way we generate customer/paymentmethod is via invoice_settings > default_payment_method

#sukatoa-customers