#blackgriffen237 - ephemeral key
deep raft
it seems like it would be a good thing to document how the library wants us to do that kind of thing, the Deserializers are all there but you have to read docs for Gson to figure out how to use them
and it seems odd that there is a dependency you have to add for Gson to use them, the Gson dependency for the Stripe code is runtime scope, not compile scope
oh and take your time, i see that its busy, no rush
outer plume
Can you explain where/why exactly you're dealing with this manually? What is your integration doing that necessitates this?
deep raft
i have a service that works with ios and im re-purposing the same exact service to also use with the web
the ephemeral key that the service for ios has an associated object of the customer which is created by the service, not the web client and the mapping is with the service so thats how the web figures out the customer
but this question is about how to really use those deserializers in the java code, not specific to the specific use case of the one I want to use
outer plume
This doesn't sounds like a recommended integration pattern -- I'm not familiar with any flows that inspect the ephemeral keys like you're describing. I'd suggest tracking the applicable customer using other techniques in your app, if you're having trouble with this approach.
deep raft
well i sort of understand but are you saying those public deserializers are not to be used?
outer plume
Which deserializers are you referring to?
outer plume
That's used to deserialize webhook data payloads eg as part of receiving webhook data: https://javadoc.io/doc/com.stripe/stripe-java/latest/com/stripe/net/Webhook.html#constructEvent(java.lang.String,java.lang.String,java.lang.String)
What does that have to do with ephemeral keys and customers?
deep raft
im not being clear
there are a number (6-7) of deserializers
under com.stripe.model
are they intended to be used by third parties or not, and if yes, then how
is the one in particular im using since the backend service already provides that thig
thing
outer plume
I'm not aware of any explicit integration pattern expected here - as far as I know this is used internally by the client and not meant to be used directly.
As I said, you should have other techniques in your application to track the relevant customer
outer plume
I don't know -- but as an internal concern I would not recommend building a deep dependency on them. They could change if we eg changed the library implementation (but kept the intended public API consistent).
deep raft
well ok