#dilkw-Payment

1 messages · Page 1 of 1 (latest)

vast knot
#

Hi, the flow you specified is correct. What do you mean by "bind the card"?

#

When we notify your system, we send webhook events which always. contains object with Id

feral adder
vast knot
feral adder
#

Is the customerId parameter required?

vast knot
#

No it's optional

feral adder
#

According to what you said, can the card list be displayed on the following page?

vast knot
#

That parameter only "attached" the Card to the Customer object. You would need to write your client code to ask your server, you server figure it out that current customer has some card attached through Stripe API, and send back information to your client, then your client would be able to display the existing card in this UI

feral adder
vast knot
#

Your client would need to send the customer id to your server, and let your server query Stripe for that card list, then respond to your client

feral adder
#

No, this page is implemented internally in the SDK, and the network request for the card list is also implemented internally

#

The original process is to add paymentMethodId and customerId when creating paymentIntent, no other operations are required, but after your first payment is successful, subsequent payments can be realized on the card list page to display the previously paid card

vast knot
#

Hi, if this is a pre-implemented by the SDK, then yes I think it would display the saved card. I have seen similar behavior in iOS SDK and Android/ReactNative should be the same. Would that answer your question?

feral adder
#

So, it can be achieved by adding the setup_future_usage parameter when creating paymentIntent?

vast knot
#

yes, I think so