#codex-paymentelement-wallet

1 messages ยท Page 1 of 1 (latest)

balmy pumiceBOT
trim gate
#

Hello again. I am looking that the Frontend can use stripe.confirmPayment() in JS to confirm Apple/Google Pay

#

Then the backend listens to a webhook async.

#

Is there a way to do this synchronously through the backend? So that the backend is the one that confirmsPayment()?

snow wyvern
#

@trim gate we recommend the flow we document, it's way cleaner/easier to implement

#

codex-paymentelement-wallet

trim gate
#

That's true, but it is difficult for testing/developing since our backend is separate from FE

snow wyvern
#

I'm not sure I understand why that would be

trim gate
#

Does there exist a way to confirmPayment() in the backend and not FE?

#

For example, if we wanted to finalize a subscription/purchase without needing the FE

snow wyvern
#

Yes and no, sorry this is a bit tricky to answer with so little details.

trim gate
#

I see. That info exists on the PaymentElement (Apple Pay element)?

snow wyvern
#

I'm sorry I am not following your train of thoughts at all right now

#

To accept a payment, you need payment details like a card number, bank account details. If you don't have any of this, you have to collect it which means you have to have some client-side code to collect it

trim gate
#

Ahh okay, but in this case we can't collect/send Apple Pay info from client-side to backend

#

So essentially there is no way to do this except the flow that is documented

snow wyvern
#

I mean there is, just it's a bad idea and you haven't explained at all why you would want this so I can't help guide you towards the right flow

trim gate
#

Right now our backend microservice that integrates with Stripe is separate from our FE. This way we can just send one POST request to the BE when developing

#

And FE app does not need to start up

#

------ So instead of the FE confirming Apple Pay, we want the FE to send details to BE and it is confirmed there synchronousl

snow wyvern
#

but why, since you still need the FE to collect Apple Pay details and then you have to go back to the FE to handle declines. That seems more than subpar

trim gate
#

But the BE microservice now relies on webhooks to save subscription info. How do we initiate a webhook for testing, with only our BE service running?

snow wyvern
#

I don't know what any of this means ๐Ÿ˜…

#

Like if it's purely for testing you can simulate this without needing the front-end

trim gate
#

Yes we use those test cards already in the BE for syncronous purchases

#

I meant with Apple Pay

#

Essentially we want: FE shows Apple Pay element -> Sends to BE -> BE confirms paymentIntent with Stripe -> BE returns success or fail to FE

snow wyvern
#

I am totally lost

#

are you talking purely about testing? Something else?

trim gate
#

Essentially we do not want to rely on async webhooks to activate purchases.

#

Reasons being testing, development, our completely separate microservice architecture, etc.

snow wyvern
#

I'm sorry this is so cryptic I don't get it

#

after all the back and forth I still don't get if you are asking for an escape hatch purely for writing unit tests or if you want your entire integration to work this way in production.

trim gate
#

No not an escape hatch for unit tests

#

We want this for prod

#

Our FE is handled by a completely separate team

snow wyvern
#

Okay so how are you doing this for non Google Pay payments today?

trim gate
#

----- Right now to test BE, we use those test cards.

snow wyvern
#

like there's no difference with PaymentElement between Google Pay and normal card payments so I don't get your question at all yet

trim gate
#

Now we are integrating with Apple/Google Pay

snow wyvern
#

Sure, let's ignore that though. How does it work right now for normal card payments.

trim gate
#

FE collects card info -> gets a token from Stripe -> sends customer + purchase info + token to BE -> BE creates customer using token + subscription on Stripe

snow wyvern
#

This is all super abstract

trim gate
#

?

snow wyvern
#

Please tell me exactly what your code is doing. You mention a "token". Are you talking about our Token API? Because you're saying "Apple Pay is different" but it's not

#

if your code calls confirmPayment() it means you have a PaymentIntent, and have PaymentElement rendered, which will collect card details the same way it does with Apple Pay, with the same flow where the confirmation happens client-side

trim gate
#

Yes right now we use stripe.createToken(elements.getElement(CardNumberElement)) and then send that token to the BE for confirming purchases

#

The Token API

snow wyvern
#

That might be obvious to you but that changes the entire discussion ๐Ÿ˜…

trim gate
#

Alright ๐Ÿ˜…

snow wyvern
#

Are you sticking with that entire integration path for cards? If so, how are you going to collect Google Pay but not card details? Because that is basically impossible if you use PaymentElement

trim gate
#

No we are okay with switching cards over to PaymentElement as well, as long as it can be done synchronously

snow wyvern
#

๐Ÿ˜…

trim gate
#

--> Like creating a Token from Apple Pay? I'm guessing that is not possible

snow wyvern
#

I'm sorry I am at a loss completely at this point

trim gate
#

?

snow wyvern
#

The flow is
1/ Create a Subscription and get the PaymentIntent's client_secret
2/ Client-side, render PaymentElement and collect payment details for the payment

That is the canonical flow for this and the right way to integrate Subscriptions today. If you don't have the FE involved you won't be able to accept many other payment methods so you're mostly going in the wrong direction and I strongly discourage you doing that.

But since we're not really understanding each other at all right now I don't think that will convince you. So you can use https://stripe.com/docs/stripe-js/elements/payment-request-button and create a Token for Google Pay or Apple Pay like you do for normal card payments and that might fit your needs

trim gate
#

I do agree that our current way is not ideal, and wish we could follow the canonical flow, but the separate nature of our architecture won't let us do this without months of work

#

---- However, we can use the PaymentRequestButton to generate a token?

snow wyvern
#

yes

trim gate
#

Is there any documentation for creating a Token using Apple Pay/PaymentRequestButton?

snow wyvern
#

I don't think we have any docs left, this was deprecated years ago

#
        paymentRequest.canMakePayment().then(function(result) {
          console.log(JSON.stringify(result));
          if (result) {
            prButton.mount('#payment-request-button');
          } else {
            document.getElementById('payment-request-button').style.display = 'none';
          }
        });

        paymentRequest.on('token', function(ev) {
          console.log(token);
        });``` I have code like this locally
#

so I'd say try this

trim gate
#

Alright, thank you for this info

#

One last thing

#

Is the Token API deprecated? And for how long has it been deprecated?

snow wyvern
#

We introduced PaymentIntent and PaymentMethod in 2018.

#

And yes we consider Token deprecated mostly since 2019. It still works, it's just not the recommended path

trim gate
#

Is there a specified timeline for when it will be removed?

snow wyvern
#

No plan to remove it no

trim gate
#

Alright I see. Thank you for working with me and my confusing explanations. But it was helpful.

#

Hope you have a great day

snow wyvern
#

All good, I understand the flow you were after now

#

but if you decided to, for example, add support for ACH Debit in the US, that flow will just not work

#

same for many other payment methods taht require a client-side redirect like iDEAl and such

trim gate
#

I see, I will bring that up to my team