#Wagyuking-3DS
1 messages · Page 1 of 1 (latest)
Hi, you can simply click on the "Accept" or "Cancel" button on the displayed popup to go forward
What software do I need to download I don't have a client
You initiated a Payment from backend?
is this software
Payments I initiate from the front end
I want to run the whole process now I want to do it in action I need to download an app to complete the 3ds verification and continue to complete the payment
are you still there
Yes but I am a bit confused
Payment need to be create server-side. How do you initiate from frontend?
The app in the screenshot is the Dashboard app, for you as a merchant to use. It's not the integration you build to show to your customer
I mean when the user pays, the 3ds is triggered. Now it is a test environment. I want to simulate the operation of the user to verify the 3ds. What should I do? Which app should I download?
look
look
Is this a form you built yourself?
status is incomplete
The code has come to this step, in fact, the user's own 3ds verification is changed.
yes
I just want to install an app on my phone pretend I'm the user go to verify 3ds let the code go on and finish the transaction
Yeah I know what you are asking. When it requires 3DS you would need to use one of our provided SDK to confirm it. We built the SDK to help you easily deal with 3DS automatically. It also strongly encounraged to use our SDK, because by building the form yourself, you are not compliant with PCI standard, exposing to the burden of submiting a lot of documents yourself
More here: https://stripe.com/docs/security/guide
thanks
Shouldn't it be this?
Yeah that one is for 3DS. But I meant before that, you should migrate over from your own form to one of our SDK, to resolve the PCI Compliance issue first. It's really more important
If you continue to send card details directly to our API, you’ll be required to upload your SAQ D annually to prove your business is PCI compliant. SAQ D is the most onerous of all the SAQs, with over 40 pages of requirements you must implement to remain PCI compliant. We highly recommend you migrate to client-side tokenization of card information to substantially reduce the scope of your PCI compliance.
When the user enters the bank card, the official one is used
I just asked for an extra email address and name. Is this form legal?
Oh you are already using Card Elements
Sorry for the miss-guide. Yes it looks good. Apologize!
But yeah this Card Element, they don't support 3DS
My English is poor. We rely on translation software to communicate. There may be some problems.
If it is not supported, why can I still pay to create an order?
This puzzles me
I recreated a normal paid order Automatically pulls up 3ds verification
Let me try again
wait
Sorry let me correct myself. For Card Element, with 3DS, I believe you can display above popup also
the CardElement does support it
This back-end interface is responsible for one-time product purchases and periodic product purchases
but
My business logic is a bit special, there is a combined purchase of one-time products and recurring products, and there is also free use, so I created another backend interface
It is this second interface that led me to collect the user's information and name, but I used the input box of the official website for the bank card. Now I have 3ds, but it cannot be automatically pulled up like the first interface. 3ds verification
That sounds strange to me, as the Card Element you are using should be able to handle 3DS by itself
Ah I see, you are using createToken in frontend
Okie I get the situation now. Instead of doing Token you should use confirmCardPayment instead. That function will automatically handle 3DS
Yes!
ok
are you still there
Yes
I and Yi calculate the price based on price_id, but ‘price_1Kir8KJkTsrU4XpcdupsSSGV’ is a periodic payment. After I create a PaymentIntent, will the user still pay periodically?
?
Sorry, looking
ok
Oh you don't need to follow the PaymentIntent creation API in the Doc. I think after you created the Subscription from your end, you can take its subscription.latest_invoice.payment_intent.client_secret to pass back to the client
It will returns the client_secret of the PaymentIntent associated with the Subscription you just created
For that specific step, refer from here: https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements#create-subscription
is this?
Yes, but when you create the Subscription, expand the latest_invoice.payment_intent to see the object
Something like this
const subscription = await stripe.subscriptions.create({
//...
expand: ['latest_invoice.payment_intent'], // Here!!!!!
});
Ignore other detail, just appending the expand part to your creation call
i try
My business logic is that there are two price_id but there is only one in the document
sorry
my question
The document is just a general example
It's totally ok to have 1 recurring Price and 1 normal Price like your code
Thank you, I have run through the process
Did it work?
Hi @graceful spoke I am archiving this thread. If you have other questions, please feel free to ask in the channel