#deathnfudge_api
sweet gladeBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1215782779015397427
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
upper agateBOT
narrow jay
@meager timber Hello! I'm sorry I don't really understand the question
meager timber
Well, we had an old purchase process we used to use that used and old version of the API (I think it was elements) and we've still been using that process to programatically create test users in our local development databases. That still works, but since we've switched to using Stripe Checkout, we've noticed some differences between how a user is created in Stripe when using the API vs. when a user goes through the Checkout process.
We'd like our test users to mimic the Stripe Checkout process, so we wanted to see if there was a newer way we should be creating test users that will have them set up like they went through the Stripe Checkout process. Since we're creating these programatically, no one actually clicks through the Checkout screens so the usual Checkout process won't work for our purposes.
We may just need to adjust the way we're creating users with the API to better match how a user would appear in Stripe after going through the Checkout process but I wanted to reach out to see if you had a newer process for this type of scenario.
narrow jay
So what exactly is not working? Checkout will create a Customer for you if needed but by default it won't. It does https://docs.stripe.com/payments/checkout/guest-customers but it's no different from what Elements does.
I'm sorry I'm still not really getting the real question you have
meager timber
Everything is working, but we're getting some different data in customer records in Stripe depending on how the customer is created.
This is for testing in our local databases. We have about 20 different scenarios covering things like a user who signs up for a subscription, one with a canceled subscription, one with a subscription with a legacy plan etc.
An example of how the customer gets created differently is the payment method gets tied to the customer record when we use the API (that may be something we need to change) but if someone signs up using Checkout by default the payment method is tied to the subscription. We may just need to change the way we're calling the API for those different scenarios. So my questions are.
Do you have a best practice around creating test users for local testing?
Should we adjust how we're calling the API to create those test users to better mimic how Stripe Checkout creates users?
narrow jay
yeah I'm really sorry you are staying super high level after 3 back and forth. You say things are different but don't way what
Can you please share exact examples of Customer ids and what exactly is different in the API for each so I can better understand the question
meager timber
Ok.
Here's an example of a customer who was created using the API.
https://dashboard.stripe.com/test/customers/cus_PgTgpGfmAQuvlM
And here's one created using Stripe Checkout.
https://dashboard.stripe.com/test/customers/cus_Ph6W9A4CIxILqt
One scenario we ran into is handling the payment_method_detatched webhook. On a customer created by the API we get the customer_id coming in directly in the webhook object
%{"data" => %{"object" => %{"customer" => customer_id}}}
On a customer created by Stripe Checkout the customer id comes in under the previous_attributes
%{"data" => %{"previous_attributes" => %{"customer" => customer_id}}}
We can account for that, but we'd like our test users to match how they're created by Stripe Checkout. I think the reason for the difference in this scenario is due to the payment method being attached to the customer record by the API and attached to the subscription when using Stripe Checkout.
I'm wanting to confirm we should adjust how we're calling the API (to attach the payment method to the subscription for instance) to better match what Stripe Checkout is doing or if there's another method we should be using. If using the API as we have been is still the best practice, I'll work on updating what we have but if there's a different way of creating test users (something like a programatic fake checkout session) I'd go that route.
The main thing that concerns us is if there are other things that differ between using the API and Stripe Checkout. We caught the payment method issue when we were handling that webhook, but if there are other differences we're unaware of, that could cause us issues down the line before we catch them so we want to make sure we're using best practices around creating test users programatically to hopefully keep from future issues.
narrow jay
thanks looking!
I don't really understand your webhook section at all. Can you share that exact information with exact Events ids?
Oh I think I get it lol
Basically you are saying that you have a really old integration where you had Customers cus_123 and they have Card object card_123 attached to them for payments
And Checkout still creates Customers cus_123 but for the card details it creates PaymetMethod objects pm_123
meager timber
Yes, that sounds correct.
We're just wanting to keep parity between the way customers are created in production and the way we're creating our test customers.
narrow jay
Okay that makes sense now!
So we (Stripe) shipped a newer API called the PaymentMethods API back in late 2018 to represent card and other payment methods in our API as we started accepting a lot more types of payment instruments.
This is a completely separate API and it goes with our PaymentIntent API that is a "state machine" for accepting payments which lets you handle cases like doing 3D Secure, redirecting to a banking partner, handling in person payments, etc.
You are using a pretty old integration where you likely create Card Tokens with Elements that look like tok_123456 and then you use those to attach the card to a Customer server-side and get card_12345 as a Card object.
Does that make sense until now?
meager timber
Yep. So we should look at updating our test user creation to use the newer API?
upper agateBOT
meager timber
We're using Elixir and Stripity Stripe as a wrapper around the API.
https://hexdocs.pm/stripity_stripe/Stripe.html
We're using Customer.create()
https://hexdocs.pm/stripity_stripe/Stripe.Customer.html#create/2
And Subscription.create()
https://hexdocs.pm/stripity_stripe/Stripe.Subscription.html#create/2
When we call Customer.create() we are passing in a map (object) with the customer email, name (if the customer entered it), and payment token.
When we call Subscription.create() we are passing in the following map (object)
%{
customer: customer,
payment_behavior: "error_if_incomplete",
items: [
%{
price: price,
quantity: quantity
}
]
}
Let me know if that's enough or if you'd like more.
narrow jay
yeah sorry it's really really hard to help because you are only giving little info
What matters is how you create the Customer. Please share the exact full code with the exact list of all parameters!
meager timber
Ok.
Here's the customer creation code we use to create a test customer.
Customer.create(
%{
email: email,
name: customer_name,
source: %{
remote_ip: {127, 0, 0, 1},
processor: "stripe",
processor_token: "tok_visa",
payment_method: "card"
}
},
[connect_timeout: 10_000, recv_timeout: 20_000]
)
yeah that is not a Stripe call
we don't have anything like processor_token so that must be some kind of abstraction from the library you use unfortunately
meager timber
Ok. I think I know what I need to do. Thanks.
narrow jay
today you likely pass tok_visa and tok_amex and such in your code