#codex-paymentelement-wallet
1 messages ยท Page 1 of 1 (latest)
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()?
@trim gate we recommend the flow we document, it's way cleaner/easier to implement
codex-paymentelement-wallet
That's true, but it is difficult for testing/developing since our backend is separate from FE
I'm not sure I understand why that would be
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
Yes and no, sorry this is a bit tricky to answer with so little details.
Like you can call https://stripe.com/docs/api/payment_intents/confirm to confirm a PaymentIntent. But you need paymeht method details to do that
I see. That info exists on the PaymentElement (Apple Pay element)?
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
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
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
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
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
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?
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
we have test cards at https://stripe.com/docs/testing#cards for this for example
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
Essentially we do not want to rely on async webhooks to activate purchases.
Reasons being testing, development, our completely separate microservice architecture, etc.
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.
No not an escape hatch for unit tests
We want this for prod
Our FE is handled by a completely separate team
Okay so how are you doing this for non Google Pay payments today?
----- Right now to test BE, we use those test cards.
like there's no difference with PaymentElement between Google Pay and normal card payments so I don't get your question at all yet
Now we are integrating with Apple/Google Pay
Sure, let's ignore that though. How does it work right now for normal card payments.
FE collects card info -> gets a token from Stripe -> sends customer + purchase info + token to BE -> BE creates customer using token + subscription on Stripe
This is all super abstract
?
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
Yes right now we use stripe.createToken(elements.getElement(CardNumberElement)) and then send that token to the BE for confirming purchases
The Token API
That might be obvious to you but that changes the entire discussion ๐
Alright ๐
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
No we are okay with switching cards over to PaymentElement as well, as long as it can be done synchronously
๐
--> Like creating a Token from Apple Pay? I'm guessing that is not possible
I'm sorry I am at a loss completely at this point
?
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
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?
yes
Is there any documentation for creating a Token using Apple Pay/PaymentRequestButton?
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
Alright, thank you for this info
One last thing
Is the Token API deprecated? And for how long has it been deprecated?
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
Is there a specified timeline for when it will be removed?
No plan to remove it no
Alright I see. Thank you for working with me and my confusing explanations. But it was helpful.
Hope you have a great day
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
I see, I will bring that up to my team