#iris-pereira_webhooks
royal boughBOT
š 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/1479197208610996425
š Have more to share? Add more details, code, screenshots, videos, etc. below.
vale sierra
hello! had a few questions come in at once but i'll get to this asap
ripe garden
its ok
vale sierra
ok, looking at this now
is your question just if you can add request_incremental_authorization_support to the PaymentIntent after it was created?
it looks like the PaymentIntent you shared pi_3T7gOdDeQbsz1rWk4ftl90T1 was created using your secret key, so i'm not quite sure what you mean regarding the hardware provider creating it on your account
if so have you tried this out in test mode?
ripe garden
Thank you!
yes, it is our Secret Key, but Relink's software is the one making the API calls using our key. We gave them our key so their terminal software could create PaymentIntents on our account. We do not control what parameters they send ā they are the ones setting request_incremental_authorization_support: false in their code.
To answer question 1: yes, exactly. The PaymentIntent is already created by Relink's software with request_incremental_authorization_support: false. Can we update that field to true on an existing PaymentIntent that is still in requires_payment_method status ā before the customer taps their card on the terminal ā using our own Secret Key?
If yes, this would solve everything because we could intercept via webhook (payment_intent.created) and immediately update the PaymentIntent before the customer pays.
vale sierra
i'm realizing that this is a preview feature so you might need to check with our support team as i unfortunately can't even test it out for you š i would be really surprised if it wasn't possible to update the PaymentIntent this way while it's in requires_payment_method but i would recommend trying it yourself in test mode / a sandbox (create the PaymentIntent and just try calling the Update API with this parameter, see if it works). and then if you have further questions you'll need to reach out to support via https://support.stripe.com/ as we can't test preview features here
ripe garden
let me give full context.
We are a powerbank rental company in Portugal. Our hardware provider (Relink) runs software on our Stripe Terminal readers using our Secret Key. We own the Stripe account, Secret Key, terminals, and saved pm_... per customer. Relink controls the software and payment parameters.
Billing: ā¬10 deposit, ā¬1/30min, ā¬10 daily max, 0 free minutes. At 4h30min the deposit is fully consumed. After that Relink always captures ā¬10 and closes the PaymentIntent regardless of actual usage time. They refuse to change their code.
Examples of what we lose: 6h = we lose ā¬2. 8h = we lose ā¬6. 24h no return = we lose ā¬25.
Our proposed solution: intercept via payment_intent.created webhook and immediately update request_incremental_authorization_support to true before customer taps, then increment every 30min ourselves and capture ā¬35 at 24h if not returned.
Q1: Can we update request_incremental_authorization_support to true on a PaymentIntent in requires_payment_method status using our Secret Key?
Q2: If yes, is the update instantaneous? The window before customer taps could be seconds.
Q3: If not possible, after Relink captures ā¬10 and closes, can we charge extra off-session using saved pm_... without customer tapping again?
Q4: For 24h no-return with PaymentIntent still in requires_capture, can we capture ā¬35 even though hold is only ā¬10?
royal boughBOT
ripe garden
š
ripe garden
i'm realizing that this is a preview feature so you might need to check with our...
Hi,
The update to request_incremental_authorization_support worked perfectly, thank you!
I have one more question.
When the customer keeps the powerbank beyond 4h30min, Relink always captures ā¬10 and closes the PaymentIntent. At that point the customer still owes extra ā for example ā¬2 for 6 hours, ā¬6 for 8 hours, etc.
Since we have the customer object (cus_...) and their saved payment method (pm_...) from the original terminal transaction ā can we create a second PaymentIntent off-session to charge the extra amount after Relink closes the first one?
Even if it is a manual process for now ā can we do this from the Stripe Dashboard without any code, just by creating a new payment using the saved pm_...?
odd frigate
Hello š
I'm stepping in as my colleague had to go.
Do you have an example of a customer with a saved payment method?
Just the ID would be enough for me to check
ripe garden
No i dont because currently is working just as a one time authorization
what i wish to do is this:
et me give full context.
We are a powerbank rental company in Portugal. Our hardware provider (Relink) runs software on our Stripe Terminal readers using our Secret Key. We own the Stripe account, Secret Key, terminals, and saved pm_... per customer. Relink controls the software and payment parameters.
Billing: ā¬10 deposit, ā¬1/30min, ā¬10 daily max, 0 free minutes. At 4h30min the deposit is fully consumed. After that Relink always captures ā¬10 and closes the PaymentIntent regardless of actual usage time. They refuse to change their code.
Examples of what we lose: 6h = we lose ā¬2. 8h = we lose ā¬6. 24h no return = we lose ā¬25.
Our proposed solution: intercept via payment_intent.created webhook and immediately update request_incremental_authorization_support to true before customer taps, then increment every 30min ourselves and capture ā¬35 at 24h if not returned.
odd frigate
Sorry but most of that means nothing to me.
ripe garden
this is the event id of a normal transaction that does not go over 04:30 hours - evt_3T7gOdDeQbsz1rWk4JqaRuxh
odd frigate
What I need to know is exactly how you collect payment method information and save it.
This payment intent is not configured to save the payment method for future use.
You need to specify the setup_future_usage parameter as we show here
If the Relink team is the ones who are configuring the Payment Intents, you would likely need to reach out to them to see if they can enable this feature
ripe garden
yes, its not saving , but unfortenatelly i brought the hardware on this company - relink but their team is williing to help to make these changes.
is not *
odd frigate
Sorry but unfortunately unless you are writing the code that creates the Payment Intents directly, there isn't much I can do to help