#Matt11

1 messages · Page 1 of 1 (latest)

solemn tendonBOT
safe jacinth
#

Hi, if you have a follow up question, feel free to write here!

lost bane
#

yep thanks

safe jacinth
#

If you use Payment Elements the authentication pop-up is displayed automatically.

lost bane
#

ok so I don't need to do other things.
Another question, I looked into redirect_url is it possible to transform it to POST? because inside my app I need to do some server stuff after the stripe confirmPayment

safe jacinth
#

No, that's not possible. Maybe you can tweak your endpoint to accept GET requests? It doesn't carry any request body anyway.

bleak cloud
#

We recommend you utilise webhooks for any async actions required post payment (e.g. listen for payment_intent.succeeded events in your webhook)

lost bane
#

@bleak cloud not possible to use webhooks because after payment I need to do database stuff and redirect to home page.
Only if the server stuff is succeeded I redirect to home

bleak cloud
#

What if your customer exits the page before your processes have ran? What if they exit the page before they're even triggered?

#

This happens, and why we only recommend webhooks to handle fulfilment/async actions like DB writes

#

Generally merchants will use the confirmPayment Promise resolve to display a 'success' page, and then separately handle any post payment actions server-side with a webhooks

#

Another question, I looked into redirect_url is it possible to transform it to POST? because inside my app I need to do some server stuff after the stripe confirmPayment
Anyway, not really sure how this is preventing you from what you want to do?

lost bane
#

thanks, I just looking for an another solution because the client would like to avoid async behaviours

#

the POST is not avoiding me to this things, just need to submit a form with data

bleak cloud
#

Ok, but what data do you need that isn't available? There's URL params appended to your redirect_url that you can use to look up the Payment Intent if that's what you need

#

The HTTP method of the redirect shouldn't prevent you from making a network request to your backend

lost bane
#

yes you're right, is to prevent people forging requests with custom params that in POST is not possible

#

the only doubt about webhooks is that I need to write essential stuff on database before making a redirect to home

bleak cloud
#

As I stated, that's not really a dependable way to ensure that 'essential' actions are done

#

If you can help me understand what you need to do after a payment, and the problems you're having then I can help understand

#

My guess is you're setting redirect_url to your backend?

lost bane
#

yes of course, thanks.
Right now I'm using old stripe tokens procedure so I'm migrating to payment intent api.

Basically the customer, after confirmPayment, need to land to homepage with an active "Subscription" row on our database.

Currently this database row is written inside the form POST also with Stripe customer creation, PI charge, etc

#

So currently in production the process is:

  • landing into checkout
  • create stripe tokens
  • submit the form with card data
  • inside POST method create the customer, create PI, pay it, create subscriptions data inside our database
  • redirect to home with everything ok
bleak cloud
#

Ok, and what difficulties are you encountering in refactoring that flow to use confirmPayment?

lost bane
#

I would like to keep the POST method as a form submit after the PI confirmPayment or 3ds popup confirmation

bleak cloud
#

Well you can still make the POST request to your backend after your user is returned to redirect_url – which should be a client-side page not a backend URL/endpoint

lost bane
#

this is the problem 😄 I don't have any "thank you page" between checkout and home page

#

I need to do everything inside this POST

bleak cloud
#

Then I'd recommend building one

lost bane
#

well I know but I'm not the product owner and I cannot decide 😄

bleak cloud
#

Well, you just can't unfortunately. Customers will always be returned to the redirect_url via a GET method

#

It's unclear to me why the webhook approach won't work:

  1. Call confirmPayment. Set redirect_url to be a 'success' page in your app/site. There you can set local app state to say that the customer is 'subscribed' and provision access.
  2. Meanwhile you configure a webhook to listen for relevant events, and make the DB writes you need in that webhook.
lost bane
#

simply because the customer doesn't want webhooks, and I cannot make him change idea

#

just need to know that we moved from stripe subscriptions and webhooks to a in-house made logic that do the same thing (with recurring jobs etc) but save everything inside our database

#

so basically I need to keep the actual behaviour but upgrading the APIs in order to let every customer pay

bleak cloud
#

Not sure what else to recommend, unfortunately

lost bane
#

thanks for your patience

#

I appreciate it

#

last question, is impossible to not redirect the customer to redirect_url?

#

so basically keep the customer in the same page

bleak cloud
lost bane
#

nice, and how can I see 'redirect-based payment methods'?

bleak cloud
#

Some BNPL are redirect methods too

#

Depends which you're offering to customers as to whether you need to handle it

lost bane
#

I'm just using cards

bleak cloud
#

Then you won't need to worry about it really

#

set redirect: 'if_required' and then you can use the result object to get PI details without a redirect

lost bane
#

cool, thanks! 🙂

zealous fjordBOT
#

This thread has been archived. If you need help with anything else please ask in #dev-help or contact Stripe Support: https://support.stripe.com/contact

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.

echo crest
#

@lost bane re-opened, what is your new question?

lost bane
#

Hello, thanks!!

I migrated my checkout to new confirmSetup function and I created a SI with:

  { customer: @stripe_customer.id, payment_method_types: ['card'], usage: 'off_session' }
)```
with this card ```4000000000003220``` and I confirmed the 3DS.

First thing, I cannot see that the payment method is the default one for the customer, why?

Second, later I try to create a payment intent in this way:
```hash = {
  amount: final_amount.to_i,
  customer: user.stripe_customer_id,
  currency: 'eur',
  payment_method: payment_method_id,
  confirm: true
}

if off_session
  hash[:off_session] = true
else
  hash[:setup_future_usage] = 'off_session'
end
::Stripe::PaymentIntent.create(hash)```

But Stripe respond again with ```authentication_required```

How can I test a card with 3DS in first place and later is automatically detected that is already confirmed?
Am I mistaken something?
echo crest
#

First thing, I cannot see that the payment method is the default one for the customer, why?
Setup intents don't automatically set default payment method as far as I am aware. That needs to be a separate call to update the Customer object and set invoice_settings.default_payment_method to the ID of that PaymentMethod https://stripe.com/docs/api/customers/update#update_customer-invoice_settings-default_payment_method

Stripe API reference – Update a customer – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

lost bane
#

ok cool I will try those solutions