#fillefilip8

1 messages ยท Page 1 of 1 (latest)

cedar carbon
#

Hello! I think Checkout with manual capture is your best bet, yeah. What are your specific concerns about that and them leaving the page?

worldly widget
#

In this use case... after payment stuff shall happen in our application (client ui). and there is no "appropriate" route to redirect the user to.

#

as its like a pay wall thing...

#

this is not a "product purchase" or so.. its a paywall for a service.. that u pay each time for

cedar carbon
#

Can you redirect to a URL that checks to see if they've paid and, if they have, allow them access to what they paid for?

worldly widget
#

umm.. not really.. its very contextual to what they currently "work on"

cedar carbon
#

Is this on a website or in a mobile app?

worldly widget
#

website. SPA

#

would it be possible to open the checkout page as "a popup"?

cedar carbon
#

No, Checkout cannot be a popup.

worldly widget
#

btw.. why cant payment intents support taxes/promo codes?

#

the documentation said it wasnt possible ever..

cedar carbon
#

You would generally redirect to a URL like https://example.com/foo?checkout_session={CHECKOUT_SESSION_ID} and then on your server check the status of the Checkout Session and proceed from there (like if they paid take them back to where they were/the next step in the process).

#

Payment Intents are low-level objects designed to facilitate the payment of a specific amount, they don't take into account things like tax, shipping, etc. That all needs to be calculated before the Payment Intent's amount is set.

#

Checkout uses Payment Intents under the hood, in fact.

worldly widget
#

in this case... its a manual capture.. so the status would be the same for atleast 10min

#

as the service gets provided.. in the background

cedar carbon
#

You can look at the Payment Intent associated with the Checkout Session and see if the hold on the funds succeeded or not.

worldly widget
#

so the checkout.success gets triggered on insuffient funds?

cedar carbon
#

No, Checkout won't succeed if there are insufficient funds.

#

So there won't be a "success" event.

worldly widget
cedar carbon
#

The card being declined for any reason, like insufficient funds, invalid card, expired card, etc.

#

In those cases Checkout will present the details of the decline to the customer and ask them to try again.

#

They won't be redirected until the hold succeeds.

#

But hang on, I didn't know we supported this on Checkout...

worldly widget
#

ah i get what u mean now..

#

support what? manual capture?

cedar carbon
#

We just don't have a guide for it.

#

Ignore me! ๐Ÿ™‚

worldly widget
#

you do have a guide for it ๐Ÿ™‚

cedar carbon
#

I'll have to flag that. ๐Ÿ˜„

worldly widget
#

Ah good!

#

So there is no possiblity to start a payment using x payment card in the background? and have the support for taxes/promo codes

#

I would need to use checkout page?

cedar carbon
worldly widget
#

i would need to know that the use can pay before i even start providing the service

#

so i doubt invoicing would work in this case

cedar carbon
#

Yep, that's true. If you need to place the hold and have automatic tax I think Checkout is really your only option.

worldly widget
#

if i need to cancel that payment.. would i cancel the payment intent then.. included in the checkout session?

cedar carbon
#

Yep.

worldly widget
#

is this the value to use to see if a checkout.session.completed = manual capture?

cedar carbon
#

If the Payment Intent's status is requires_capture the funds are on hold but have not yet been captured.

worldly widget
#

i mean it cant be "paid" if its manual capture?

#

but i get what you mean... the "safest" way is to check the status of the payment intent

#

but i guess webhooks can be delayed too

cedar carbon
#

I think the Checkout Session's payment_status will transition to paid after you capture the funds, but it's not something I've tested.

worldly widget
#

yeah most likely.. but its safer to check the payment intent as you said ๐Ÿ™‚

cedar carbon
#

Yep!

#

For your situation what I would recommend is something like this:

  1. Set up a Checkout session to place a hold and redirect to something like https://example.com/foo?checkout_session={CHECKOUT_SESSION_ID}
  2. On your server, get the Checkout Session ID provided and retrieve the Checkout Session with the Payment Intent expanded (so you only have to make one API call to get both
  3. Check the status of the Payment Intent to decide what should happen next
worldly widget
#

the payment intent gets captured later.. the user does not need to know the status of it

#

the only thing that matters is that the user has the funds for that payment intent ... on the "authorize"

#

as the capture happens in the background without user interaction

cedar carbon
#

Yeah, I'm not saying the user needs to know about or see it.

#

I'm saying your server does.

#

In order to know if the hold was successful or not.

#

Does that make sense?

worldly widget
#

.. but hold is always successful?... checkout succeeds?

#

or?

cedar carbon
#

Not sure what you're asking, can you provide more details?

worldly widget
#

when i recieve a checkout.session.success... that means the "authorize" step of the payment is successful? correct?

cedar carbon
#

I think so, but let me test to make sure.

worldly widget
#

also whats "card_present" as payment method type?

cedar carbon
#

Yeah, checkout.session.completed fires when the hold succeeds and the Checkout Session's Payment Intent has a status of requires_capture.

#

It means the card is physically present.

worldly widget
#

ahh!