#uwotnate-terminal
halcyon owl
my application currently exists as an online store running in the customer's browser. my goal is to augment this to provide the option for an in-person kiosk, accepting payments through a Stripe Terminal reader rather than Stripe Elements.
so I guess it's actually two questions (it was a trap!)
-
is it possible to use the Server-driven integration à la the BBPOS WisePOS E readers? My reading of the docs says no, but I just wanted to confirm before I wrote that option off completely.
-
ideally I would like to avoid reimplenting the application as a native iOS app just to access the iOS Terminal SDK. Is there a world where it makes sense to build a barebones iOS app that handles PaymentIntents created from the JS application (fulfilling them through the Terminal reader of choice), or is this a Bad Idea™?
exotic mirage
- Can you clarify what specific part of the docs is pushing you to believe that the server driven integration isn't an option for you?
halcyon owl
sure, I was reading this page for accepting payments using an NFC iPhone. it talks about the feature being an extension of the iOS SDK, and it doesn't seem clear that there is a way to register an iPhone as reader in the way that the Server-driven integration requires
exotic mirage
Ahhh gotcha - I forgot about the Tap to Pay aspect. Yeah, you're right then - you won't be able to use the Server-driven integration is Tap to pay is necessary for you
halcyon owl
that's unfortunate, but I appreciate the confirmation!
so re: my second question, it seems like the iOS SDK is still, fundamentally, just grabbing a PaymentIntent and fulfilling it. so, in theory at least, i could write a small iOS app that pulls down a PaymentIntent created by my JS application and sends it to a reader to complete the payment. does that seem like it might make sense, or is that a terrible idea?
exotic mirage
For your second question I think I see what you're getting at - while yes, we do offer the ability to create Payment Intents directly through the ios terminal sdk, it's not a requirement to use and you can certainly use the PIs that you already have created
With that being said "barebones" is a bit subjective here - payment intent creation is a really small part of the payment process for terminal, and your app will still need a lot of functionality to be able to collect reader payment end to end
halcyon owl
hah, "barebones" might not be exactly the right word, but it would certainly mean not reimplementing all of the customer UX that goes into determining what the PI should be and then maintaining both versions. I kind of just wanted to gut check the idea of doing all that work in an existing browser app and then handling the Stripe Terminal bits in a native app that is agnostic of the customer experience. it would essentially just receive a PI and then handle the negotiation with a reader until the PI is either fulfilled or cancelled. does that make sense?
exotic mirage
Yup! I think overall that makes sense - from the perspective of the ios app it doesn't really matter where the PI is coming from as long as it gets it
halcyon owl
awesome, appreciate the help here! just out of curiosity, do you think the Tap to Pay integration would ever support the Server-driven integration?
exotic mirage
As far as I know there isn't a way to support it with the server-driven integration since it's a native mobile feature
halcyon owl
gotcha, fair enough. thanks @exotic mirage !