january_code

[modern barn]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1506470867008356534

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[solar rivet]

Could you share the errored request id req_xxx? From your Dashboard request log

[ornate quarry]

Hi Orakaro, good morning.

Here's the req id

req_fLbd8Uzh7cIb9M

For context, the idea is to trigger setup_future_usage so that I can use the payment method to be reusable via saving it to a customer, not a guest customer

[solar rivet]

Hi, are you creating PI on backend, then use its client secret to initialize the Elements on frontend?

this.stripeElement = this.getStripe.elements({
 mode: "payment",
 currency: getCur.toLowerCase(),
 amount: 200,
 paymentMethodCreation: "manual",
 setup_future_usage: "off_session",
});

these code looks like the Defer flow, which is creating PI after collecting card info.

But req_fLbd8Uzh7cIb9M on pi_3TVkKvD2CzZDU24j0ydTmoRV and thisis creating PI before collecting card info

[ornate quarry]

yes, I created PI on the backend to get the client secret

here's the complete order of the code

this.stripeElement = this.getStripe.elements({
mode: "payment",
currency: getCur.toLowerCase(),
amount: 200,
paymentMethodCreation: "manual",
setup_future_usage: "off_session",
});

const expressCheckoutOptions = {
buttonType: {
applePay: "donate",
},
paymentMethods: {
applePay: "always",
googlePay: "never",
paypal: "never",
link: "never",
klarna: "never",
amazonPay: "never",
},
buttonHeight: 48,
buttonTheme: {
applePay: "black",
},
};

const expressCheckoutElement = this.stripeElement.create(
"expressCheckout",
expressCheckoutOptions,
);

expressCheckoutElement.on("confirm", async (event) => {
try {
const paymentMethodId = event.paymentMethod.id;

if (!this.clientSecret) {
await this.handlerClientSecret();
}

if (this.clientSecret) {
const result = await this.getStripe.confirmPayment({
clientSecret: this.clientSecret,
confirmParams: {
return_url:
"https://computing-app-1537-dev-ed.scratch.my.site.com/posipay/s/posipay-payment-form",
},
elements: this.stripeElement,
redirect: "if_required",
});

 if (result.error) {
   event.complete("fail");
 } else {
   event.complete("success");
 }

}

this.errorMessageFooter = "";
} catch (error) {
this.errorMessageFooter = error.message;
}
});

[solar rivet]

Ty! Gimme time to look closer

So it does look like that setup_future_usage: off_session wasn't sent in frontend. Despite your code have it

this.stripeElement = this.getStripe.elements({
 mode: "payment",
 currency: getCur.toLowerCase(),
 amount: 200,
 paymentMethodCreation: "manual",
 setup_future_usage: "off_session",
});

Could you double (triple) check your deployed code on your production site?

[ornate quarry]

yes, it was there

[solar rivet]

Do you have a live website which can reproduce?

[ornate quarry]

It is not live yet but

can I confirm, in frontend, where should I put setup_future_usage?

is it in the expressCheckoutOptions param? in stripeElement.create function?

[solar rivet]

stripe.elements as you are doing: https://docs.stripe.com/elements/express-checkout-element/accept-a-payment?payment-ui=elements#additional-options:~:text=and subscription mode-,setupFutureUsage,-off_session

[ornate quarry]

Okay got it

Answer question tho

During my testing, I noticed that an Invoice is being created for the applepay transactions.
My intention is to process the payments directly through a PaymentIntent flow using the element, without involving Stripe Billing or invoice-based processing.
Could you please confirm whether there is a specific Stripe configuration or implementation approach required to avoid Invoice creation and ensure the transaction uses PaymentIntent processing only?

[solar rivet]

I don't see an Invoice for pi_3TVkKvD2CzZDU24j0ydTmoRV. Where do you see it?

[ornate quarry]

nevermind that, the invoice was originally comes from a subscription which is not related to the applepay transaction

Thanks, Orakaro. Last question.

Zero-amount transaction usage to create reusable payment methods
I saw suggestions that applepay can be used with a 0-amount PaymentIntent to generate a reusable payment method and customer. Is this a supported pattern, or are there any risks or constraints we should be aware of when implementing this approach?

Is that really possible? Creating the payment method as reusable using ApplePay via stripe checkout element without initiating a payment?

[solar rivet]

That's Express Checkout Elements with "setup" mode, which will create a SetupIntent. That's essentially 0-amount PaymentIntent

mode: 'setup'

[modern barn]

⛔️ Stripe developers have stepped away for a short while

Please leave your questions here, and we’ll respond as soon as we're back! If you need help urgently, you can contact Stripe support for help.

[ornate quarry]

Actually, I was looking for something like saving it on a customer instead of setup intent. I need to trigger the payment method creation from appleapay without the payment. Like probably skip the

expressCheckoutElement.on("confirm", async (event) => {
try {
const paymentMethodId = event.paymentMethod.id;

[pliant pivot]

Hello, I am teddy, taking over the shift from my colleague, do give me some time to catch up!

I was looking for something like saving it on a customer instead of setup intent.

if you choose Express Checkout Element (mode:setup) + SetupIntents that has an associated Customer object, the payment method will automatically get associated to that Customer