#azuken_unexpected
1 messages ยท Page 1 of 1 (latest)
๐ 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/1460635570333024288
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- azuken_error, 1 day ago, 13 messages
FYI, my payload to create checkout session on my BFF :
const params: Stripe.Checkout.SessionCreateParams = {
adaptive_pricing: { enabled: isAdaptivePricingAvailable(cart.country) },
line_items: cart.lineItems.map((lineItem) => ({
price_data: {
currency: lineItem.price.value.currencyCode.toLowerCase(),
product_data: {
description: lineItem.variant.attributes?.[0].value.name,
images: lineItem.variant.images?.map((image) => image.url),
metadata: {
cart_line_item_id: lineItem.id,
product_id: lineItem.productId,
},
name: cart?.locale ? lineItem.name[cart.locale] : '-',
},
unit_amount: lineItem.totalPrice.centAmount / lineItem.quantity,
},
quantity: 1,
})),
metadata: {
cart_id: cart.id,
},
mode: 'payment',
ui_mode: 'custom',
};
hey there, taking a look
hmm interesting
Can you tell me more about how/why you're using the metadata set on the server session create in the client side app?
Broadly speaking, we consider metadata to be a server side only structure because it often includes private details you wouldn't want revealed client side
For example when receiving a payment intent client side (before or after payment) you don't get metadata either
Hey !
My usage is to update UI, if user is using adaptive pricing, and set the converted prices to line items. As my line items are based on my commerce data (Commercetools), I want to match line items from CT and line items from Stripe, to get the right price
Here is the UI to get a better look at my need
I managed to get the right price by comparing product name, but it's really not ideal (user changes his language, it breaks)
What exactly are you trying to look up in metadata?
For displaying the line item amounts, I would expect the session line item amounts to also be converted based on the currency selection. Is that not what you're observing?
I want to have the line item ID from my e-commerce data (Commercetools), to match with Stripe data
Because I can have both cases : show price from my e-commerce data, if adaptive pricing is not enabled, or show price from Stripe Checkout Session if enabled
I cannot base my line items only on checkout session line items, because of my business cases and rules
(you can see my metadata here)
And here is a sample of my cart line item front component:
<template v-if="addressStore.isAdaptivePricing">
<UiText class="!text-xl" styled>
{{ paymentStore.checkoutSession?.lineItems.find((li) => li.name === item.name)?.total.amount }}
<!-- TODO: replace with li.metadata.cart_line_item_id when lib will provide it -->
</UiText>
</template>
This sample is in a loop of my line items in cart entity from Commercetools
If I do not use adaptive pricing, I make my own label with Commercetools amount / currency (with differents cases like discounts, offers, price by quantity etc...)
Can you say more about this? Because I think this is what you're going to need to do for the time being, barring any other work around we can figure out. Alongside the session id/client secret you could send a trimmed object of the line items array with the line item id and your internal product ID or the same metadata, then your client app would use that as a lookup.
We have multiple constraints here:
- We don't have to use adaptive pricing when selected currency is already euro, so we show to user data from ecommerce, and checkout session is just here for payment intent purpose (I've just implemented checkout session, in replacement of classic payment intent flow)
- We are using another provider for Paypal payments, here we don't need to have adaptive too
- We have use cases about promotional offers (from user or from cart), we must adapt UI to show the right final price to user, and these data are not in checkout session info
In that last case, how are you managing the session payment amounts if you have discounts calculated outside of the session object?
I'm getting the sense that your constraints might be conflicting with the embedded component functionality and you might need to revert to the payment intent + elements integration
Because i think this approach could help you handle the line item <> internal product ID aspect, but doesnt address the other concerns
Final price is calculated on server side, and transmitted to checkout session when I'm creating it. It's mainly a UI issue here.
I tried to have both implementations working aside but it was too complicated to maintain properly
But you can't dictate just the final price for the checkout session, it is calculated from the line items, discounts and tax automatically
I think I have no choice but send metadata from session into cart entity
Yes, and I send to CS only final price (which is already calculated for the discount part)
Right, if that unblocks you then i recommend just creating this lookup object and sending it to client side alongside the session secret
You're effectively using checkout session like a payment intent in that case, which is going to come with a bunch of caveats and limitations, since youre not really using the core line item logic etc
But if it gets you the end result you want then great
I think a manual mapping of the lines <> products is where you need to explore next
And hopefully that gets you what you need
Indeed, it is mainly constraints from my client needs ๐ฌ payment intent process was easier and cleaner, but they want adaptive pricing with "current behavior" of previously implemented payment intent
Thanks for the tips though!
Do you want to share your account ID that youre building this with? (acct_123) I can pass it along to the Adaptive Pricing team so that if they have questions about your use case for future functionality they can get in touch.
Yes, sure! Here is my account ID : acct_1JaKRZC0v6iyzO0e
Shared that - thanks!