#hendr1x_api

1 messages ¡ Page 1 of 1 (latest)

dull zenithBOT
#

👋 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/1369295163742228614

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

craggy sundial
#

hi there!

azure geyser
#

Hello

craggy sundial
#

which API version are you using? the latest one (Basil)?

azure geyser
#

I've never been asked that

#

I'm using php sdk 16.5.0

craggy sundial
#

I'm asking about your Stripe API version.
if you are using an old API version, then you can find the PaymentIntent in the payment_intent property of the invoice.

azure geyser
#

How do I determine that?

#

I don't believe I choose an endpoint

#

I assume its hardcoded into the sdk

#

I just found this

# 
class ApiVersion
{
    const CURRENT = '2025-01-27.acacia';
`
}
dull zenithBOT
azure geyser
#

Looks like I need update my sdk

#

So, I still need an answer to original question

craggy sundial
#

Got it! I did answer:

if you are using an old API version, then you can find the PaymentIntent in the payment_intent property of the invoice.

azure geyser
#

I need the id

#

and I'm going to use the newest version

#

I assume?

#

I can't imagine its a good idea to use an old version

craggy sundial
#

I need the id
you are looking for the PaymentIntent ID of the Invoice? I did explain how to find it, it's in the payment_intent property since you are not using the Basil API version.

azure geyser
#

Lets start again

#

I am going to upgrade my sdk because I assume that is the right choice to avoid issues down the road

#

I just download 17.2.0 and it says it runs from basil

craggy sundial
#

got it

azure geyser
#

Sorry...I need to give you more information

#

I'm starting this code off by creating a subscription

#

So it seems like to get the paymentIntent ID from a subscription create call I need to do 3 calls?

#

$stripe->subscriptions->create($intent);

#

$stripe->invoices->retrieve()

#

$stripe->invoicePayments->all()

craggy sundial
#

when you create the subscription, you can use expand to directly retrive the latest_invoice

#

so that would be 2 API calls in total:

  • create the subscription (while retrieving the invoice)
  • then list the payment for the invoice
#

and if your goal is just to retrive the client secret, then a single API call is needed (create the subscription with expand latest_invoice.confirmation_secret)

azure geyser
#

I need the id and the secret

#

So I need to expand to get the latest_invoice variable?

storm ivy
#

What do you need the id for?

azure geyser
#

Or does expanding give me more info than just the id

azure geyser
storm ivy
#

Expanding the latest_invoice.confirmation_secret will get you the entire invoice object, including the ID. The confirmation_secret will include the client secret needed for client side confirmation of the payment

#

It will not include a payment intent ID

#

If you specifically wish to record the PI id, you'll have to retrieve that using the InvoicePayments API as described earlier

#

(Aside, just stepping in as soma needs to step away)

azure geyser
#

Can I please clarify one things

#

When I get a response from a subscription create

#

does it include latest_invoice?

#

or do I need to expand to get that

storm ivy
#

The response by default will have latest_invoice=in_12345 --- some invoice ID only

#

Expansion turns that ID into an object

#

It's to consolidate create+retrieve into a single request for convenience

#

So you expand to get the invoice object, typically to access the client secret for front end payment collection

#

And for that purpose you also must expand confirmation_secret starting from the basil releases

azure geyser
#

ok...but it seems like I don't need to expand. I can use the invoice ID to call invoicePayments

#

But it looks like that doesn't include the secret...lol

#

ok...so I guess I have to expand latest_invoice.confirmation_secret to get that

#

$stripe->subscriptions->create($intent, ['expand' => ['latest_invoice.confirmation_secret']])

#

Nope....that doesn't work

storm ivy
#

In what way? What happens?

#

Can you share the request ID?

azure geyser
#

I'll figure it out I guess

#

Can you just tell me if there is any help from upgrading the api to basil?

#

I'm using the php sdk

#

I just upgraded from 16.5 to 17.2

#

am I going to have issues?

#

It was acacia prior

storm ivy
#

you can click into each one for more details, such as affected fields by server language

azure geyser
#

Perfect

#

thank you for your help. I appreciate it.

storm ivy
azure geyser
#

even better!

azure geyser
#

I'd like to ask another question. Your system says do not open a new thread.

#

I'm getting the following error

#

The customer does not have a payment method with the ID pm_1RLleSCTw3MsNtCvKxuccLIu. The payment method must be attached to the customer.

#

I'm generating the paymentMethod via your elements JS system.

#

How do I attach a customer exactly?

#

The error comes from calling subscription->create() in PHP (server side)

storm ivy
#

Can you share the request ID?

azure geyser
#

req_UvtkK93FvG4Up5

#

I think?

dull zenithBOT
storm ivy
#

It appears that you're using createPaymentMethod in Stripe.js here

azure geyser
#

correct

storm ivy
#

You should instead confirm the payment/setup intent in Stripe.js after creating the subscription

azure geyser
#

The error message I provided before is me trying to create the subscription

storm ivy
azure geyser
#

So I can't confirm the paymentIntent because of this error

storm ivy
#

I'm suggesting you have things in the wrong order, or if you want to collect details first and confirm (create subscription and pay) server side, you need to modify the sequence

azure geyser
#

Wait

#

thats not what I want

#

I am collecting payment on one page, then generating subscription, then confirming payment

#

paymentConfirmation is done in JS

#

collecting payment is in JS

#

generating subscription is server side

storm ivy
#

You should not be using createPaymentMethod for the flow you describe

#

and instead creating the subscription without a payment method, using payment_behavior=default_incomplete and then confirming client side like you say you want

storm ivy
#

Your current integration does not match this

azure geyser
#

That setup will not work for me

#

My checkout flow has payment on one page, then a cofirmation page then a complete page

#

this cannot be changed

#

Please advise

storm ivy
#

I see, in that case you should use confirmation tokens, but need to combine steps from different guides (going to share feedback about this)

azure geyser
#

I can't use confirmationTokens....I tried and they were not able to work iwht payments saved to account

storm ivy
#

Can you say more about that? WHat do you mean?

azure geyser
#

All I remeber is what I have in my notes

# 
createConfirmationToken was used but caused the following issues
saved payments on account used paymentMethod so I had to support both
confirmSetup had support for using confirmationTokens but I was told it not standard to use and might cause issues
#

I keep going down these approaches in your system and then hit dead ends

trim onyx
#

Using confirmationTokens with confirmSetup is definitely a standard way to use that. There may have been a miscommunication somewhere around this

azure geyser
#

I can't keep track of thenm all

trim onyx
#

The current best way to do your flow is to create a confirmation token on one page and use it to confirm your intent on the next page

azure geyser
#

So recode everything to use confirmationTokens?

#

That will resolve my issue that I'm dealing with now

#

and is fully supported by setupIntent + paymentIntent

#

and the use of saved payment on an accounts?

#

Looking at the documentation I don't see how to use saved payment methods

trim onyx
azure geyser
#

its all currently built and running off payment method

#

you are saying I need to use confirmation tokens, but they aren't just a straight drop in replacement

trim onyx
#

Correct

#

Confirmation tokens are used for the initial payment or setup, that creates a payment method, from that point on you use the payment method

azure geyser
#

Your terms are hard for me to keep straight. Please bear with me.

#

This is very frustrating as I had this all coded months ago

#

So, I am on the payment page of my checkout

#

I am currently using elements + createPaymentMethod

#

I need to change that to createConfirmationToken

#

So it returns a paymentMethod

#

whats different between that and createPaymentMethod?

#

Sorry...I got the docs messed up

#

createConfirmationToken returns a token

#

ConfirmationToken

#

So why are you saying it creates a payment method

trim onyx
#

Has this been largely working for months? If so you might just need a smaller tweak

azure geyser
#

I need this to be done correctly

#

I started this discussion just trying to finish up the last part of the system...subscriptions

#

But if I need to use confirmationTokens I will

#

All I can say is, at one point I used confirmationTokens and I couldn't get them to work and what I thought I was told was they would not work in my use case

trim onyx
#

Alright, taking a step back, your integration largely works but occasionally you run in to the "customer does not have a payment method with the ID pm_123" like you did in the last request you shared?

azure geyser
#

At this point, setupIntent and paymentIntent works perfectly

#

I am now trying to add subscriptions

#

The checkout flow goes payment page, confirmation page, complete page

#

the payment page allows for saved account payment methods, or using your JS elements + createPaymentMethod

#

on the confirmation Page, first server side, I am trying to create a subscription and getting the error I posted above

#

I was then planning on confirming the paymentMethod using your JS system

trim onyx
#

Gotcha, so the solution here is actually much more straightforward here

azure geyser
#

sorry...I just edited... I am now trying to add subscriptions

trim onyx
#

So instead of providing the PM id when creating the subscription, you will want to confirm the subscription's first payment or setup intent with the PM, the same way you'd do with a PI or SI that you created directly

azure geyser
#

for PI + SI I currently pass in payment method when I create server side

trim onyx
#

Ah so slightly different, you'll get the PI or SI ID when you create the subscription and then make another call to confirm it with the PM that you have already created

azure geyser
#

I would rather standardize everything to the same format

#

So if I stop adding payment method to PI + SI on server side create, I can just do it on confirmation to make it the same as subscription?

#

and that will get rid of the original subscription error that I ran into at the start of this? "The customer does not have a payment method with the ID "

trim onyx
#

Not quite sure what you mean here unfortunately. What do you mean by standardize to the same format?

azure geyser
#

If possible I want PI + SI + subscriptions to run from the same checkout flow

#

in this case...when I provide payment_method

#

So, it seems like I can just stop providing payment_method on my server side create and provide it when I confirm and that will make all of them the same flow

#

can you confirm and can you also confirm this change will stop the error I originally started this discussion with

azure geyser
trim onyx
#

You can keep the exact same flow you have now and add subscriptions. The one difference is that for subscriptions you need to make a create call and a confirm call instead of just a confirm call. Unfortunately there isn't a way to create a subscription and confirm its first intent with a PM that hasn't been attached to a customer yet

azure geyser
#

I'm not sure I understand. PI + SI require a clientSercret so doesn't that mean I need to create call for them?

#

(before my confirm call)

trim onyx
#

Okay I misunderstood. So what you can do here is expand the subscription's latest_invoice.payment_intent field and pending_setup_intent field, get the client secret from there, and confirmt eh intents as you have been already

azure geyser
#

Yep I've got that part coded but not tested. So, for PI + SI + Subscriptions, I can create them server side, NOT provide a payment_method and then provide it during confirmation?

#

That will resolve my error with payment_method not being attached to customer as well right?

trim onyx
#

yep

azure geyser
#

Ok...that sounds great.

#

Can I just ask something quick about confirmationTokens. Do I have to worry about my current approach being depricated at some point?

#

This program hasn't launched yet and I would rather get stuff dealt with before launch.

trim onyx
#

There aren't any current plans to deprecate your flow, and we still support flows that are much older. So no immediate concern there. And we do make sure to proactively communicate on deprecations well in advance, so there would be a warning period

#

And this isn't a drop in change, but it isn't an enourmous one. It is mostly changing how the initial payment happens. The basic process is:

  1. Create a confirmation token
  2. Confirm your PI/SI with the CT
  3. Step 2 creates a PM and attaches it to the customer (assuming the PI has setup_future_usage set), that PM can can be used for future API calls to re-use the payment method
azure geyser
#

Ok, I think I'm going to explore doing the change now to see how hard it is on my end. How do confirmation tokens work when I want to use saved payment methods on an account.

#

I currently just store the PM in my database in provide it during checkout. I don't remember the issue but I'm guessing that will not work with confirmation tokens

trim onyx
#

Gotcha. And to be clear on that last part, I was more trying to say that down the line if this does get deprecated, the switch isn't that big so you would have plenty of time to make it in future. You can defintely keep your flow as is and just make the tweak we were discussing

azure geyser
#

Understood

#

If its only a day or two of work I'll just get it over with....if it ends up being more than that I will probably wait

#

From very old notes I had to issues with confirmationTokens.

#
  1. confirmSetup had support for using confirmationTokens but I was told it not standard to use and might cause issues
#

I was told this is not an issue any longer

#
  1. saved payments on account used paymentMethod so I had to support both
#

I don't want to have to use both paymentMethods + ConfirmationTokens. I think the only thing that would force me to do that is managing saved payment methods for customers.

#

Is there a way to use confirmationTokens + save them for future use for customers?

trim onyx
#

Confirmation tokens are one time use, they are only meant to be used to create a PM and then that is what is used from then on.

dull zenithBOT
azure geyser
#

So it sounds like I can't get rid of PM then?

#

If I wanted to switch to Confirmation Tokens and support saved payment methods on accounts, I would create the PM from the confirmation token and save that for further use and my system would have to support both correct?

trim onyx
#

The confirmation tokens would only be used for paying with/saving new payment methods, payment methods would be for any payment that uses a previously saved payment method. So I wouldn't use the phrase "support both" because they have distinct purposes here, but that may just be a matter of phrasing

azure geyser
#

Alright.

#

I appreciate your patience!