#Sadness ;'(

1 messages · Page 1 of 1 (latest)

exotic sandBOT
dark axle
#

👋 happy to help

#

give me a few minutes I will be with you shortly

mossy dust
dark axle
#

there's not an easy way of handling this to be honest

#

you need to contact our support team https://support.stripe.com/?contact=true to see whether you're eligible to enter this beta

Stripe: Help & Support

Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.

mossy dust
dark axle
#

yes

mossy dust
#

Why is it in beta? What changes are made to the API? I can not see any.

mossy dust
#

Does it support LPM's? And wallets? Like Apple Pay or Google Pay

dark axle
dark axle
mossy dust
dark axle
#

in this beta yes

mossy dust
# dark axle yes

I think that this payment flow is the best option for me. But this only runs actions before confirmation. What if user didn't authorized the payment via 3DS? Then when the payment intent will be cancelled?

dark axle
#

the 3DS gets called before submitting the payment in the next step

mossy dust
dark axle
mossy dust
#

Here? ```js
const form = document.getElementById('payment-form');

form.addEventListener('submit', async (event) => {
// We don't want to let default form submission happen here,
// which would refresh the page.
event.preventDefault();

const result = await stripe.updatePaymentIntent({
elements, // elements instance
params: {
payment_method_data: {
billing_details: { ... }
},
shipping: { ... }
}
});

stripePaymentMethodHandler(result);
});```

dark axle
#

yes

mossy dust
#

So then why this step (8) is needed: ```js
const handleServerResponse = async (response) => {
if (response.error) {
// Show error from server on payment form
} else if (response.requires_action) {
// Use Stripe.js to handle the required next action
const {
error: errorAction,
paymentIntent
} = await stripe.handleNextAction({
clientSecret: response.payment_intent_client_secret
});

if (errorAction) {
  // Show error from Stripe.js in payment form
} else {
  // Actions handled, show success message
}

} else {
// No actions needed, show success message
}
}```

dark axle
#

because even if the 3DS was passed in the previous step the issuing bank might (under they're own discretion) ask for another 3DS auth

mossy dust
dark axle
#

it doesn't get cancelled

#

it would still be in a requires_action state

mossy dust
dark axle
#

yes until either they get the 3DS confirmation or you cancel them explicitly

mossy dust
#

So then how i can "unblock" the item? It will be blocked all the time.

dark axle
#

you can actually create a time-based task to run after x amount of time and if after that time the PI didn't succeed you cancel it

#

and it will trigger the webhook that would "unblock" your item

mossy dust
dark axle
#

unfortunately with only PI you can't specify an "expiry" time

mossy dust
#

So there is not any clean solution?

dark axle
#

only what I previously suggested, you can skip the webhook part and automatically do the logic in that time-based trigger

mossy dust
dark axle
#

you shouldn't run the scheduler on the same machine as your server

#

this is normally part of a decentralized architecture or a micro-services architecture

mossy dust
#

yes it is possible to solve CPU load like that, but as I said that it is not the only reason why this solution is bad.

#

Like it just does not seems to be clean

dark axle
#

Clean is a really stretchable word to be honest

#

anything could be clean if you code correctly and you have it follow a certain process that you put in place and you document it internally

mossy dust
dark axle
#

yes but you also need to be pragmatic and find the solution that works instead of criticizing it without having a backup plan

mossy dust
#

I think that i actually found one.

#

But it depends on one fact: Can i run custom actions before the money is tried to be transffered from user to my stripe account?

#

Thats the solution: If the user is on the 'requires_action' step i can (Can I?) release the item "block" because of the fact that another user can in this time buy it. But i need to again "block" it right before the action succededs to avoid buying one thing twice.

dark axle
#

that would also require a lot of coding in an "unclean" manner as you would say

#

I think it's possible

mossy dust
mossy dust
dark axle
#

because there's a lot of edge cases that you can't really control

mossy dust
dark axle
#

If the user is on the 'requires_action' step i can (Can I?) release the item "block" because of the fact that another user can in this time buy it. But i need to again "block" it right before the action succeeds to avoid buying one thing twice.
how would you go by implementing this (in your opinion)?

#

from the front-end? listening to a webhook event? etc...

#

if you are triggering the "unblock"/"block" from the front-end what guarantees that the customer won't close their webpage and you would be stuck with a state that you don't actually want because some front-end code wasn't called

mossy dust
mossy dust
dark axle
#

@mossy dust I'm not sure you're going in the right direction here

#

A time-based scenario is the best option you have here IMO, something like a customer can hold a "product" for x amount of time. If they don't pay through this window, the "product" gets released

#

and the PaymentIntent gets canceled

mossy dust
#

BRB

dark axle
#

I might not be around when you do come back, feel free to head to #dev-help and ask for help again