#nova-astramentis_api

1 messages ยท Page 1 of 1 (latest)

rotund gorgeBOT
#

๐Ÿ‘‹ 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/1354960629802209382

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

young totem
#

More information I couldn't fit in your ticket:

We need a single 'source of truth' for payment methods because some of our integration is heavily customized (such as cloning cards across connect accounts). Since the checkout product does not support this use case, we want any payment methods created via SetupIntent to be available during the elements.js checkout flow. Barring this, a solution to allow us to select any payment method would be much appreciated.

Is there something here we are doing wrong, or some undocumented flag I can send to allow this?

opal hornet
#

If you're on a beta, I'm going to have to send you to Support, as that's not something we can help with from here.

young totem
#

I just spent half an hour with support ๐Ÿ˜ฆ

opal hornet
#

Damn. ๐Ÿ˜ฆ

#

Ok let me peek a bit. Can you share the Customer ID where it worked?

young totem
#

customer_id of the platform account, or the dev user who is testing checkout

opal hornet
#

Not Stripe Account ID, the Customer ID whose card successfully showed up on a subsequent Checkout Session.

young totem
#

cus_NoaXFeKqcLdjTd

#

I have a screenshot that might help too

#

Top PM didnt work, bottom one did.

#

Seems to be anything saved via paymentIntent works (which is why CustomerSession can be used), but setupIntent is different.

opal hornet
#

That seems weird.

young totem
#

I do notice the one via setupIntent has an incomplete billing address, is there something related to that?

opal hornet
#

Maybe. There's way too much data in that Customer for me to dig. Can you try with a new test customer to just save the card (different cards ideally) both ways via Checkout and see which shows up and which does not the next time - and share the Request IDs for all of those so we can dig into them further?

young totem
#

I believe I can, give me one moment

#

cus_NrkYNpMcwfCR3G

#

let me dig up request ids

opal hornet
#

I can do that.

young totem
#

I just need to create a checkout session for that customer real quick and confirm it

opal hornet
#

So I think the way you're creating the SetupIntents is the issue.

young totem
#

When its confirmed, we pass confirmParams.payment_method_data.allow_redisplay = always

opal hornet
#

(fixed it)

young totem
#

I love you guys, but your docs are hilarious.

opal hornet
#

Tell me more?

young totem
#

/s or real feedback?

opal hornet
#

I'm curious, and I don't necessarily disagree either - just curious as to your experience.

young totem
#

Oh I just run face first into some hilarious pain points. Switching from embedded to custom checkout, certain parameters are no longer valid and the docs say they are conditionally required (but when? Who knows)

#

Docs get you 70% the way there, reading the source code of the java-sdk is the remaining 30% sometimes

opal hornet
#

Ya that's unfortunately fair. It has become an incredibly capable & powerful platform, but that cost complexity.

young totem
#

Alright, so I had a read on that page.

#

I need to create something like this along with the setupIntent?

#

Pass both to the front end, and both combine into the payment element that can save for on-session?

#

If I specify off_session, is it capable of doing off AND on-session payments?

opal hornet
#

It's always capable of doing on-session payments, because the customer will be on-session to verify if needed.

#

Cards saved to a Customer under an 'old way' of doing so will not render as a saved card in Checkout no matter what you do, so updating the way you do SetupIntents should do it.

young totem
#

It implies that setting customer_id is all you need

#

I just wanna document this for the next guy ๐Ÿ™‚

opal hornet
#

It should, yes.

#

During payment is different - is that what you're doing?

#

Did I give you the wrong docs? :sigh:

young totem
#

Maybe? We set up using elementsjs on one page, and create a checkout session (setting customer ID) on another

#

I cant find the docs for the thing you originally sent me on customer sessions

rotund gorgeBOT
opal hornet
#

Awesome. Me neither.

young totem
#

The bit that I am worried about is that I don't have a paymentIntent due to being in a checkout flow

native skiff
#

๐Ÿ‘‹ Hello, taking over and catching up. Please allow me some times for verifying before getting back

young totem
#

Hello! Appreciate your time and effort. I might have to step away for a little while, but i promise I will respond ๐Ÿ™‚

opal hornet
#

(Honestly you're in better hands now - good luck! ๐Ÿ™‚ )

young totem
opal hornet
#

Good or bad, hard to know. ๐Ÿคช

Have a good one!

๐Ÿช„

rotund gorgeBOT
young totem
#

Okay. We are going to test updating that and using the CustomerSession object when saving a payment method through elementsjs

#

Will report back here if anything works ๐Ÿ™‚

native skiff
#

Sure and good luck. And I am fully on your feedback about 70% working and 30% hilarious painful. We are working on that area

#

I feel the same way ๐Ÿ™‚

#

The Doc is great as looking at it, but it lacks something when you look into it

young totem
#

While you are at it, can you ask your java sdk engineers to please, please, please consider a mode where sub-messages are not embedded

#

Having to write CheckoutSessionCreateParams.PaymentMethodConfigurationParams vs CheckoutSessionUpdateParams.PaymentMethodConfigurationParams is despair

#

Have you seen the java sdk or used it at all?

#

The same object (payment method configuration) has 30 signatures. One for each create and update method. So you need to use fully qualified imports everywhere, and you cannot share any code because they arent the same object

#

So if you had something that converts a DTO to a LineItem, you need a method to do that for SubscriptionCreate, SubscriptionUpdate and LineItemCreate

native skiff
#

I don't use Java SDK TBH but I can definitely foward your feedback! To clarify, you would love to have 1 same object, which can be used in either SubscriptionCreate and SubscriptionUpdate, correct?

young totem
#

Yeah. It would be really nice to be able to use com.stripe.model.LineItem everywhere

#

If you have a subscription manager, you will be importing four different LineItem objects, one in each method for CRUD

native skiff
#

Could you send me the link to CheckoutSessionCreateParams.PaymentMethodConfigurationParams ? Looking at master and don't find either of them

#

(Maybe you are on a different version)

young totem
#

It was an example, I can send you an actual code snippet

#

See these two screenshots. One is for updating a subscription, the other is for creating a subscription

#

Identical code, but you can't write a common method because the Item class is embedded in SubscriptionUpdateParams and SubscriptionCreateParams respectively.

#

They don't share a common ancestor, so oftentimes you have to write code that looks like this

#

If I tried to use that same features block (which is just configuring payment elements) anywhere else, the objects arent the same

native skiff
#

I follow until

because the Item class is embedded in SubscriptionUpdateParams and SubscriptionCreateParams respectively
But the next screenshot is about CustomerSessions rather than Subscription, right? Sorry lost here

young totem
#

Ah.

Screenshots 1 and 2 show that two different operations (subscription.create and subscription.update) do not share a common LineItem, so you cannot reuse logic in creating these objects.

Screenshot 3 shows that the syntax for creating objects also becomes extremely verbose, since you have to import the object you want using the fully qualified name.

#

In java you cant import multiple classes with the same name, so if you have duplicate names you have to use fully qualified class names instead (which can be 50+ characters in this case)

native skiff
#

I see. Is there any type alias in Java?

young totem
#

Alas, no

#

No such thing as import {ClassName as FooClass} from "@types/Foo"

native skiff
#

Thanks. Making sure I understand the feedback ๐Ÿ™‚ So in a better world, if there is one universal SubscriptionLineItem type, then it would be easier to reuse it, and shorter to reference it, correct?

young totem
#

Absolutely! To handle cases where a parameter isnt supported for a particular operation, overriding the setX method to throw an exception would be much preferrable.

#

An example being when updating a subscription, some parameters available when creating a subscription aren't present.

native skiff
#

So the universal object would have a mode-ish attribute indicating whether new or update, then on each overriding look at that indicator

#

Gotchas

young totem
#

Yep. A common ancestor being available would go a very long way. That way I could have a method that returns a generic com.stripe.model.LineItem, and can subclass it into the correct type of LineItem if I wanted perfect type safety, or use the generic one (understanding limitations) if I dont

native skiff
#

Hmm do you mean having 3 LineItem classes, one is the universal, generic, and 2 subclasses for Create and Update?

young totem
#

Yes, exactly. I understand why the dev team chose to do this (you can never set an invalid param accidentally using the nested types), so I don't want to trample over their hard work. Allowing me to choose an unsafe route would be an addition, not a replacement

native skiff
#

Got it. Thanks for patiently explaining. Will file this one

young totem
#

You good. This is a personal want of mine, so I appreciate even being heard ๐Ÿ™‚

young totem
#

Okay, so we updated our integration to provide stripe more information. What we cannot figure out is how to give the payment method an email, which your docs say is required

#

Still doesn't show up in checkout sessions, but this is what we got so far. How would we attach an email to this payment method using a setupIntent?

native skiff
#

Okie, how are you currently collecting this SetupIntent? Also via Checkout?

young totem
#

No. We create a setupIntent + customer session, get them to enter all the info using stripe elements, and everything is asked for except the payment method email

#

Then, the payment method email is blank, and the method doesnt appear in checkout

#

Okay, we have managed to get a single card appearing on the checkout session.

Turns out the stripe elements integration will not fill in the email from the customer's configured email address.

You have to manually provide the email in setupIntent.confirm under the key payment_method_data.billing_details.email

#

Now the oddity, every time we add a new card it replaces the old card in saved_payment_methods

native skiff
#

Yeah that works, if you already have the email, otherwise you can prefill to the Payment Elements so it can carry over to the SetupIntent too

young totem
#

Funny enough, we did prefill

#

Doesn't work if you use defaultValues

#

Works for every other field except email

#

How do we show more than a single card in saved_methods? I saw somewhere that 3 should be presented by default

#

(Defined by CustomerSession payment_method_redisplay_limit)

native skiff
#

if you look at your Customer in Dashboard, do you see 3 PMs?

#

Yes, right?

young totem
#

I see like 30

#

2 are valid

native skiff
#

2 both have email + all the address?

young totem
#

pm_1R7TYsKvrNqDdLmfcHdsZy5z, pm_1R7TWNKvrNqDdLmf12jGNkbX,
pm_1R7TTnKvrNqDdLmfDqZdtHuX

on customer cus_NoaXFeKqcLdjTd

native skiff
#

Since you are re-displaying in Checkout, it follows a different logic. I am afraid we haven't exposed any setting for Checkout yet

#

Checkout is more of prebuilt box, which has less optimization than Elements

young totem
#

Beans. I am being informed though that anything that shows up in PaymentMethod is valid as part of checkout.confirm

#

Its not throwing errors at least for those methods. What would a valid replacement for the checkout element be in this case?

#

Just use Payment element, track the selection, plop the ID?

native skiff
#

Yeah how about also using the regular PaymentElements for re-displaying? Would you see 2 PMs there?

#

Could you double (triple) check if all these PMs here satisfied the conditions:

pm_1R7TYsKvrNqDdLmfcHdsZy5z, pm_1R7TWNKvrNqDdLmf12jGNkbX,
pm_1R7TTnKvrNqDdLmfDqZdtHuX

young totem
#

1R...5z = OK
1R...bX = OK
1R...uX = OK

#

I also keep PCI-compliant references mirroring stripe in my database (we attempt to use as few remote calls as physically possible, everything is webhooks).

So i don't /really/ need the payment element, I can just use the record in the database

#

So just to confirm, for our custom checkout case:

  1. Initialize stripe checkout.
  2. Provide a PaymentElement (or otherwise) showing all 'complete' payment methods.
  3. Write our own logic for displaying line items, pricing, taxes, etc.
  4. User selects a payment item, we send that along with session.confirm()

???

profit?

rotund gorgeBOT
tawdry egret
#

that sounds correct, you'll usually want to test it out to make sure everything works as expected.

young totem
#

Yup, it's just been a bit of a Herculean effort to get to this point, so i just needed confirmation that the expected use case is to bypass saved_payment_methods entirely by using a PaymentElement (since currently you can't modify the number of returned payment methods in the checkout session)

#

Maybe a beta_7 feature? espeon_cool_wink

tawdry egret
#

we'll share that feedback!

#

this might be helpful to get a POC up and running quickly. We have a quickstart sample here for the Payment Element which you can modify : https://docs.stripe.com/payments/quickstart

Learn how to embed a custom Stripe payment form in your website or application. Build a checkout form with Elements to complete a payment using various payment methods.

young totem
#

I'm just happy that you guys went insofar as creating ui_mode custom by the way.

My first pass I had to write everything myself because my client wanted to style checkout. So for all my bitching, thanks for all putting in all the effort to help me out!

#

As for the demo, I looked at your source code and have a pretty good idea, but I appreciate the document. I will forward it to our web dev

tawdry egret
#

if you or your webdev has more questions or run into other issues, feel free to reach out again on Discord!

rotund gorgeBOT