#warrenn1_api

1 messages · Page 1 of 1 (latest)

whole basinBOT
#

đź‘‹ 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/1283186603585704018

đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.

stiff ocean
#

Hi there

#

For any long-running holds, one way you can model this is to keep track of when a hold will expire and then make a second authorization. If that fails, you can decide to capture the amount from the original bid/auth

last bone
stiff ocean
#

A 30 day hold still won't really solve your use case though

last bone
stiff ocean
#

Just what I mentioned above re: "stringing" holds together until you hit your desired time frame for the hold

#

Otherwise, you could not place a hold at all and just collect payment details using SetupIntents. If someone wins the bid, you can make an off-session payment at that time. If the off-session payment fails, you can decide whether to prompt them for new payment details or move on to the next highest bidder

last bone
#

How do you do an off session payment?

#

That sounds ideal.

stiff ocean
#

The end of this details how to use a saved PaymentMethod when the customer is off session

last bone
#

Okay so just so I am perfectly understanding this.

  1. On account setup, I can save a customers card information.
  2. Then on my platform they can do all the necessary bids etc.
  3. Then if they win the bid I can use the stripe_customer_id associated with the user that won the bid to get their Card Info they saved earlier.
  4. I can use that along with a payment attempt server side to execute the charge WITHOUT bogging the customer down with approval stuff etc.
  5. If that fails, I can notify the customer they need to resubmit payment.

Does this sound correct?

#

Thank you again for all of your help. It is deeply appreciated.

#

I love your guys' product and what you do at Stripe and would love to use it for all the payment services my business will require.

whole basinBOT
stiff ocean
#

Yep, that's right!

#

Though note that, even if you're confirming payment server side, the issuing bank might still need additional authentication/action from the customer. In that case, you'll need to have the customer come back on session and confirm the payment client side

last bone
#

Because ideally I would basically like them to sign a slip going "Yes I consent to you charging me X amount at this later date." Then I get a token back representing that promise and then when the time comes I use their saved card with that token to charge them that exact amount.

stiff ocean
#

If the payment needs additional action, the PaymentIntent will be in requires_action state

last bone
#

I am assuming I still need to create a CheckoutSession for the customer then?

last bone
stiff ocean
#

No, you wouldn't use Checkout to confirm such a payment. Checkout should only be used when someone is signing up for the first time/the first time you're collecting payment details from them. It's not possible to use Checkout to confirm an existing PI

last bone
#

Okay. So is it:

  1. I get the card info. Then I make the payment intent server side and then charge the card. No user interaction necessary.
    Or
  2. I get the card info. I then prompt the user with a payment intent on checkout. I save that payment intent for later in my db. I can then fulfill it when the bid succeeds by using the attached card.
stiff ocean
#

I don't quite follow # 2 or why this is an "or" scenario

last bone
#

One involves user authorization for a specific payment amount via your guys’ api. Then other is I store the bids in my DB and execute payment when bids finalize.

stiff ocean
#

Let's try to be really clear here

#

Taking one step back so I use the right terms. Are you currently using Checkout Sessions in payment mode with payment_intent_data.capture_method: manual for creating holds?

last bone
#

No. I am building from the ground up with you guys.

#

I am open to any process to achieve the result I am looking for.

stiff ocean
#

I get the card info
How are you currently doing this?

last bone
#

Using the setup intents endpoint.

stiff ocean
#

and the PaymentElement?

last bone
stiff ocean
#

Right, what are you using on the frontend to collect these details?

last bone
#

The essence of my question boils down to:

I want to create something that a user can simply say “yes if the bid succeeds, please use this card information and billing info and charge me this agreed upon amount.”

last bone
# stiff ocean Right, what are you using on the frontend to collect these details?

As for the Frontend, I am not focused on that. I simply want to know how to basically go:

  1. Save the customer card info with us for later on setup of their account.
  2. When the user confirms all of their bids, have them approve for a set of payments to be made later IF the bid goes through.
  3. When their bid goes through, I use their card they saved with us with the approval they made for the future payment in the bidding step to perform the transaction without asking the user to consent a 2nd time.
#

What would be the exact steps to do the above?

#

I will use whatever Frontend elements are necessary if I can get the above behavior.

stiff ocean
#

So yes, you would use SetupIntents for this. For step # 1 , up to you if you use Checkout Sessions in setup mode or create a SetupIntent server side and use the PaymentElement client side to collect their card info

#

For #2, that sounds like it happens completely outside of Stripe, at least until you have to use the amount from those bids to actually create a payment in #3. Is that accurate?

last bone
#

In step 2 I would ideally like the promissory aspect to happen via Stripe. When the user goes “yes I promise to pay these amounts” stripe generates a promise I can store with their bid on my end. I then track when/if the bid goes through. ** I then use that promise for later with their information to perform the transaction solely server side **. If this can be done via checkout, payment intents etc. I don’t care. I just need it to function this way.

#

If that is not possible, then I am okay with what you implied where I store all that info on my end and then perform the payment in step #3. However, I would like this to only happen server side and only require the client if absolutely necessary (ie. the payment fails).

last bone
stiff ocean
#

When the user goes “yes I promise to pay these amounts” stripe generates a promise I can store with their bid on my end.
The only real option for this is a hold but we've ruled that out due to time frames. SetupIntents are the next best thing as confirming a SetupIntent client side (when the user provides their payment details) is essentially them granting you permission to complete future off-session payments with the saved payment details

#

So, for #2, you'd still need to collect and track their bid amount so you know what to charge them for #3. When their bid goes through, you can attempt an off-session charge server side but there's no 100% guarantee that this charge will go through or not require additional customer authentication. That's purely a decision on the issuing banks side

last bone
stiff ocean
#

Right

last bone
#

Okay. Thank you for that information. That helps a lot.