#Wagyuking-3DS

1 messages · Page 1 of 1 (latest)

dusk prawn
#

Hi, you can simply click on the "Accept" or "Cancel" button on the displayed popup to go forward

graceful spoke
#

What software do I need to download I don't have a client

dusk prawn
#

You initiated a Payment from backend?

graceful spoke
#

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

dusk prawn
#

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

graceful spoke
#

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?

dusk prawn
#

Is this a form you built yourself?

graceful spoke
#

status is incomplete

#

The code has come to this step, in fact, the user's own 3ds verification is changed.

graceful spoke
#

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

dusk prawn
#

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

graceful spoke
#

thanks

#

Shouldn't it be this?

dusk prawn
#

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.

graceful spoke
#

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?

dusk prawn
#

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

graceful spoke
#

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

dusk prawn
#

Let me try again

graceful spoke
#

wait

dusk prawn
#

Sorry let me correct myself. For Card Element, with 3DS, I believe you can display above popup also

#

the CardElement does support it

graceful spoke
#

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

dusk prawn
#

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

graceful spoke
#

I did use it in the front end for the second interface

dusk prawn
#

Okie I get the situation now. Instead of doing Token you should use confirmCardPayment instead. That function will automatically handle 3DS

graceful spoke
#

thanks Let me see

#

is this?

dusk prawn
#

Yes!

graceful spoke
#

ok

graceful spoke
#

are you still there

dusk prawn
#

Yes

graceful spoke
#

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?

#

?

dusk prawn
#

Sorry, looking

graceful spoke
#

ok

dusk prawn
#

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

graceful spoke
#

is this?

dusk prawn
#

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

graceful spoke
#

i try

#

My business logic is that there are two price_id but there is only one in the document

#

sorry

#

my question

dusk prawn
#

The document is just a general example

#

It's totally ok to have 1 recurring Price and 1 normal Price like your code

graceful spoke
#

Thank you, I have run through the process

dusk prawn
#

Did it work?

dusk prawn
#

Hi @graceful spoke I am archiving this thread. If you have other questions, please feel free to ask in the channel