#marius_api
crude rapidsBOT
👋 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/1402033427212927188
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
next ruin
👋 Hi, Do you have an example request ID that demonstrates the undesired behavior?
stray mountain
Hi, yes, 1 moment
I think this is the one req_KwyOVirAPNHZOP
Can i print the request id from the api or lonly from strip dashboard?
next ruin
you can get it from the response header of any call but other wise it's gonna be found in your dashboard logs
do you have another example where https://docs.stripe.com/api/invoices/object#invoice_object-confirmation_secret-client_secret was available when you wen tlooking for it
stray mountain
but i don';t have under latest_invoice
i can use that one you mentioned for the mobile device?
for example, check req_7ZmfHao5cG99Fd
i have a charges object
same data in the request field, but the response is different
next ruin
Sorry, I was going off your original message which suggested you were looking for the client_secret under the latest_invoice in subscription and that it was only available some times.
Looking over your Payment Intent reqs
stray mountain
That is correct, i need client_secret under the latest_invoice
same request every time, different behaivour on the response
next ruin
Request ID's you provided aren't Subscription creation requests, one is a Payment Intent creation and the other is a Payment Intent capture.
stray mountain
hmmmm
$subscription = \Stripe\Subscription::create([
'customer' => $customer,
'items' => [['price' => $stripePrice->id]],
'payment_behavior' => 'default_incomplete',
'expand' => ['latest_invoice.payment_intent'],
"metadata" => ["recurrency_id" => $recurrencyId, "name" => $msisdn, "receiver_country" => $receiverCountry, "sender_country" => $siftUser->country],
]);
This is the code i'm using
next ruin
Also what API version are you using?
stray mountain
v8.12.0
next ruin
Looks like
2015-07-28
next ruin
The reason I asked is our latest API made some changes to where you th Payment Intent lives so I wanted to check. It's not relevant to your issue in this case.
stray mountain
i'm using stripe from composer, so not sure what api method is triggerd in the backend
next ruin
If you have have Req id's for the one show casing the proper behavior and one showing improper behavior, that would help me idenitfy where the difference lies. I'm looking through your request logs now.
stray mountain
req_7ZmfHao5cG99Fd this is proper behavior,
i can change the api version if you think this will fix it
wait
next ruin
Shouldn't be needed, I just needed to know because your current code works with older api version but would not work with our current one
stray mountain
this are the logs from the live platform?
next ruin
Their is a optoin to toggle between live and test mode
in the dashoard on the right hand side
I found some examples I'm just looking over them now
First thing i'm noticing is in some casea you are using a Setup Intent and others you are not.
next ruin
no worries
stray mountain
req_HAHFV0SDBQ5J85 -> BAD
req_385fIhb1TB1uYY -> GOOD -- you can see that here thre is a valid 'latest_invoice' object
next ruin
Appreciate your patience
stray mountain
and sometime the payment_intent objet in latest_invoice is missing
for instance in this one req_2w6OOFR1rkNvhZ
no worries., i'm the one that should thank about your patience
this req_IJiZDeMP9vWOU8 is also GOOD
so, i'm a little confused about how this should work
next ruin
So what i've noticed, is when you create a subscription, and the customer has 0 account balance, our Subscription API creates a Payment Intent, and a client secret key is available.
When the customer has an account balance, that covers the full cost of the subscription, it uses the account balance, and instead creates a setup_intent to save the payment information, which in turn results in their being no client secret on the invoice.
So the difference in behavior comes down to the Customer having a pre-existing account balance large enough to cover the Subscription cost
because the invoice is being finalized, and paid automatically with the Customer Balance.
next ruin
I know, I compared two examples
stray mountain
so remember, i need this data to be sent to the mobile device
and the billing information will come from there, or i am missing something?
next ruin
in one example the customer had 48 cents in their customer balance when you created the subscription. It used those 48 cents, and thus didn't need to create a payment intent, and there was nothing that needed confirmation on the invoice.
In the other attempt, that same customer had a balance of zero.
stray mountain
and if it is a new customer?
next ruin
A new customer wouldn't have any pre-existing funds
crude rapidsBOT
next ruin
I think the key here is when the customer has a pre-existing balance thats enough to cover the cost, it's just saving a the payment information and pulling from the balance so there is nothing to confirm as invoice is finalized already.
stray mountain
Let me check with mobile team what i can return in that case