#loterak_api

1 messages · Page 1 of 1 (latest)

scenic ivyBOT
#

👋 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/1308430197133148270

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

charred lodge
#

hi! yeah, I don't think there's really a way to do that since we don't support sending line items for the PaymentElement. Apple Pay would just show the amount on the PaymentIntent from your Subscription's first invoice, which is the after-discount total.

dim forge
#

Right now the user is seeing the following which is the amount sent when the payment element is created.

But as you can see in the background, we want to discount them for 25% of the price.

On the manual CC flow, when a user submits the payment we create a subscription with the necessary info, and get a client_secret that's later used by confirmPayment().

What happens with Apple pay and other payment methods that have their own UI? Does it do the whole confirm payment flow with whatever amount was first sent when creating the payment element?

image.png
charred lodge
dim forge
#

Okay so by updating the amount the user will get charged correctly at least.

The issue with that is we won't be able to link the amount to the actual promo-code/coupon that was used to grant them the discount.

charred lodge
#

true, yes

#

we have plans for future products that will let you use the PaymentElement but get the benefits of Checkout features like line items and discounts, so that will eventually be the solution here:
https://docs.stripe.com/checkout/custom-checkout

#

Okay so by updating the amount the user will get charged correctly at least.
to clarify, the user is charged the amount on your PaymentIntent. The amount on the frontend/popup doesn't change what their actual card is charged

#

but obviously yes you'd want them to match to avoid customer confusion/complaints/disputes etc

#

also I notice you say "we create a subscription on the default_incomplete state, and apply the discount to that" , does that actually work in practise or is it just your plan? Because I think you might have a common misunderstanding, which is that you expect that an incomplete subscription can be used as a "draft" while you edit/change details on the checkout page; but it doesn't, the Invoice of an incomplete Subscription is already finalized and locked. The only real solution to having a draft is to use our Checkout product, or build your own bespoke UI that manages all the updates and only creates the Subscription at the very end, or use that Custom Checkout product when that is fully ready

dim forge
#

That seems to be working in practice yes, we've had the custom checkout UI running for a few months already.

I would say we are doing exaclty what you described here:
build your own bespoke UI that manages all the updates and only creates the Subscription at the very end

charred lodge
#

sounds good!

dim forge
#

So the last piece I'm not fully understanding is when is that PaymentIntent getting created in the case of Apple/Google Pay.

#

becuase on the manual CC flow we get the payment intent after user submits all payment info. We create the subscription on our backend and use the subscription.latest_invoice.payment_intent&.client_secret to finalize the payment in the client

charred lodge
#

yes, that's when it's created, when you create the Subscription.

dim forge
#

yeah pretty sure that's the doc we followed

charred lodge
#

you can see that the Subscription(and thus the PaymentIntent) is created when you submit the form and call your backend. This flow all works the same regardless of payment method overall

image.png
scenic ivyBOT
charred lodge
#

it is assumed that you're tracking the total on the frontend and updating it as you go using the method I mentioned earlier(so that at the point you call elements.submit() which show the Apple UI, it has the right amount), and that you end up creating the Subscription with details that lead it to having a matching amount

dim forge
#

okay so users should be getting charged correctly, and it's just a matter of them not seeing the right UI because we are not changing it with the update

charred lodge
#

yep

#

for completeness I'll mention that the update function https://docs.stripe.com/js/elements_object/create_without_intent#stripe_elements_no_intent-options-amount is a bit of a pain to use. It's async but doesn't return a Promise, instead you have to listen to an event to know the update happened. https://docs.stripe.com/js/element/events/on_update_end That makes it more complicated to do something like "only update the amount when the form submits" , which otherwise is a good approach here.
(
i.e. if you do like elements.update({amount:finalSubtotal}); await elements.submit(), the Apple UI might still show the old amount because the update didn't finish
)

dim forge
#

thank you for the heads up!

dim forge
#

One last question! Because my region doesn't support Apple Pay so I won't be able to easily test it.

After you go through the Apple Pay flow you still need to click my custom submit button in order to subscribe?

placid dagger
#

👋 howdy, karllekko had to step away so I'm here to help now

Briefly, no, that should not be necessary unless you want an additional final step in your flow after payment details have been provided.

#

You can call confirmPayment after elements.submit() succeeds and you get your intent from the subscription creation

dim forge
#

I'm doing that last piece in the logic after you click my custom submit button. But I'm having a hard time understanding if an Apple pay flow would go through that code or not.

If it doesn't then the subscription would never get the discount correctly applied.

placid dagger
#

Are you using confirmation tokens to create a two-step flow? I don't completely understan what you mean by this:

I'm doing that last piece in the logic after you click my custom submit button.

#

If you could share your submit handler sequence that might help

#

But I'd expect to you would handle Apple Pay the same way

dim forge
#

not sure if this helps at all but here's the template of payment element component we created:

<form id="payment-form" data-test-stripe-payment-element>
  <div
    id="payment-element"
    {{did-insert this.mountStripePaymentElement}}
    data-test-payment-element-container
  >
    {{! Stripe will create form elements here }}
  </div>

  <BU::Divider id="payment-divider" class="my-24" />

  {{yield}}

  {{#if @paymentInProcess}}
    <wb-loading-indicator class="my-24" data-test-payment-element-loading />
  {{else}}
    <BU::Button
      @onClick={{@submitPayment}}
      @variant="primary"
      id="payment-submit"
      class="w-full my-24"
      data-test-payment-element-submit
    >
      {{t "buttons.subscribe"}}
    </BU::Button>
  {{/if}}

  <p id="payment-terms" class="type-body-s">
    {{t "consumer.checkout.paymentSection.terms"}}
  </p>
</form>

The submitPayment function that gets triggered by clicking the subscribe button is the only logic that triggers:

  1. a stripeElements.submit()

  2. a request to create a default_incomplete subscription so we can get the paymentIntent client_secret

  3. a stripeInstance.confirmPayment(client_secret) that finalizes the ceremony and charges the customer

placid dagger
#

Right, so that would apply to Apple Pay too then. The browser UI is triggered by that elements.submit() call and the details are using during confirmPayment.

dim forge
#

Ohh okay so the Apple Pay UI won't show up until elements.submit() is executed?

placid dagger
#

Correct

dim forge
#

Perfect! Thank you 😁