#dagvaar
crude kiln
Hello 👋
I believe it refers to the client-side code. The machine that's running your client-side code should be on the same network as the reader when you use JavaScript SDK with WisePOS E
If you want purely server-driven flow then you'd need to use Server Driven SDK instead
steel patio
Im confused, I thought the java code was to be uploaded on the POS device?
In the example there is a Java and PHP part, where do I upload the Java part if not on the Android device?
crude kiln
Can you share the link of the code you're looking at?
It could be an android app code
steel patio
Cause if this is the case, the device and client side app are the same thing and they indeed are on the same network, the prhase above would be unnecessary
Also it is not clear what is the pro/con of using Js respect server driven integration
Why do I need a checkout page if I'm doing the payment using a POS?
I need something really trivial, the in-person customer pay on my POS device and the money goes to Stripe.
tawdry kernelBOT
crude kiln
I think there's a misunderstanding somewhere. Let me give a brief explaination on how the Terminal Integration with Stripe works.
The reader is controlled by Client-Side SDK (JS/iOS/Android/React Native). The person controlling your POS would have some UI component that they can interact with to connect to the reader and collect payment.
The PaymentIntents that are used are created and captured by Sripe server-side SDKs (Ruby/Python/PHP/Java etc).
The checkout page in the docs refer to POS User Interface
steel patio
So is the Java/Kotlin code supposed to be uploaded on the POS?
crude kiln
No, If you're building an Android app in Java/Kotlin then you'd install it on a separate android device.
steel patio
So I don't need that part
crude kiln
So the communication will happen as following
Reader <---> Code running on your POS (Android App) <---> Your backend code (PHP) <---> Stripe APIs
steel patio
The POS is already sending the data over the PHP side?
The Code running on your POS (Android App) is the Java in the example in the link I guess?
In this case the sentence in the docs "The reader must connect to the same local network as your point of sale application." do actually refer to a local PHP server, since we said the code is uploaded on my POS?
crude kiln
The Code running on your POS (Android App) is the Java in the example in the link I guess?
Can you share a screenshot with the code you're referring to? You linked the guide that's for JavaScript client-side SDK integration
Let's take a step back
When you say "POS" what exactly are you thinking of?
crude kiln
Okay that's where the misunderstanding is. Let me explain..
From Stripe's perspective, POS is a combination of the device/reader that collects cards like the WisePOS E + the machine that runs the code to control the behaviour of the reader.
WisePOS E and other readers can't run the code themselves. So no, you don't upload the code on the readers themselves.
For example, think of walmart.
When you scan items at the checkout, it shows up on the screen and when you click "pay", that's when the reader comes in.
The screen that shows items in your cart, is referred to as POS
steel patio
Oh no I need something much more trivial
Customer come at checkout, cashier enter the amount on the device, the customer pay.
Imagine a restaurant, people finish their lunch and the waiter bring the device (POS) to their table (or they reach the cashier) to proceed with payment, the waiter or cashier enter the amount the customer(s) needs to pay.
We son't have Walmart here so not much practical.
crude kiln
That walmart usecase is just an example, POS can be trivial too.
You as a developer decide what your POS does and all. Stripe provides the SDKs that you can use to do it.
steel patio
Why is the example providing code for Android if I don't upload code on the device?
crude kiln
Why is the example providing code for Android if I don't upload code on the device?
That's for merchants who want to control the reader via an android tablet or other android devices
steel patio
Ok, not our use case though
crude kiln
the waiter or cashier enter the amount the customer(s) needs to pay.
There's no way to enter the amount directly on the Reader today.
steel patio
Can we still use the reader to process payments?
So we need reader + a phone or tablet to set the amount?
crude kiln
You can, you'd still need some UI/front-end that the waiter/cashier can interact with
So we need reader + a phone or tablet to set the amount?
yes, a phone or tablet or a computer that can run Terminal SDK
steel patio
Can a PC do that too?
Restaurants do use it for table checkout and reservation would be more simple than another phone or tablet
crude kiln
Yes. For a PC, you can write a web app that uses JavaScript SDK (in which case the reader would have to be on the same network as the PC) or Server Driven SDK.
steel patio
What is the difference?
sage fractal
Hi 👋
You can read about how these approaches differ here: https://stripe.com/docs/terminal/payments/setup-integration
steel patio
Since we can use a PC, could it be a PHP as well?
sage fractal
The Server-Driven integration uses Stripe client libraries so yes you can use PHP
steel patio
I think I'm still missing one step
I dont see a PHP example on this page
Im at this step
Set up your integration
Set up a Stripe Terminal SDK or server-driven integration to accept in-person payments.
If I got what we said so far, this is to control the device where customers can make payments
So I can for example set the total they need to pay
sage fractal
I think you need to slow down and actually read the docs on Terminal integrations thoroughly
If you need to see PHP code snippets you can start here: https://stripe.com/docs/terminal/payments/connect-reader
steel patio
Im trying to figure this out, thats why we are here. For example, why does it make a distinction between client and server in this case where the reader is controlled by a PC running a PHP server?
Server side is missing JavaScript integration in the toggle menu, this is confusing for me
sage fractal
Because for the POS you still need an interface the person controlling the reader uses
It's basically building a web application (with both server & client sides) to control the terminal reader
steel patio
I was following the link you provided and on step 2 I got a 404
I read smart readers are controlled by Stripe API, would't be more simple to use one of those instead?
sage fractal
That is what the Server driven integration does
I think you are trying to move too fast and need to read through the documentation carefully.
steel patio
I need to get the strings to refer with my customer to tell him what he needs to run Stripe solution
If we can use the PC he is using for table reservations it is one device less he needs to buy
I think server driven is the way like you said
Just POs application and back-end coincide in this case If I read it right
sage fractal
The POS is both back-end and front-end
The reader is just how to get the data from a card
For web applications the end customer interfaces with the front-end
steel patio
So I can link the reader to Stripe account and operate it using a PHP app on some server, is this correct?
sage fractal
In the terminal scenario, the merchant uses the front-end to control the reader
Yes, you handle all the interactions using PHP on the server side
But like a PHP website, there is a front-end too
steel patio
So client and server side in this case are the same thing
sage fractal
They can be
steel patio
If by client side is where we set the payment amount
sage fractal
That is entirely up to your application design
steel patio
In this case the PHP will run over the web, not on the same network as the reader, would this be ok?
sage fractal
Yes
As long as you are using the Wise POS E then both the reader and the POS just need to be connected to the internet, not on the same network
steel patio
Ideally customer can login to payment.hiswebsite.com where is the backend and enter the amount, there via API stripe will talk with the reader and process the payment, then with webhooks the page will notify the merchant the payment was processed.
sage fractal
Sure, you can build it that way
steel patio
Would that be canon or is there a better way?
sage fractal
We have all our recommendations in our docs
steel patio
I take this is not optimal then?
sage fractal
That isn't what I said
steel patio
Ok let's take this path, I read we can use simulated readers to test it before buying one
Sales told me you will send an e-mail receipt to the customer, do we need to collect email adress or do you email to the adress associated with customer credit card in this case?
sage fractal
Your system would need to collect and set the email by updating the payment intent: https://stripe.com/docs/api/payment_intents/update?lang=python#update_payment_intent-receipt_email
steel patio
Is this referring to where the server is located? For example if my server is located in the US and the business in the EU do I still need to write to get server-driven access?
sage fractal
No that won't work AFAIK
steel patio
Do I need to have a server in the same country?
sage fractal
Yes
But you could reach out to the beta team listed in that note and see if the beta program offers more features
steel patio
Weird, ok Ill write to them, where do I find Stripe API docs?
sage fractal
steel patio
I dont se any mention to the Wise POS reader
sage fractal
Where are you looking?
This is a good doc for figuring out which reader you need: https://stripe.com/docs/terminal/payments/setup-reader
steel patio
The link you gave me say "online or recurring" payments not in-person
sage fractal
Can you be more specific
steel patio
Can you be more specific
In the API I could not find where it connects to the BBPOS WisePOS E
sage fractal
The Wise POS E is a reader. so you probably want to look at the docs that are on how you connect to a reader
steel patio
I get a 404 page not found when I click the second step
sage fractal
What do you mean "when I click the second step"?
steel patio
the link would be https://stripe.com/docs/terminale/payments/collect-payment
maybe the link has a typo
ok got it its terminal without e
sage fractal
Oh so this is some odd localization. Thanks for calling this out
steel patio
yes looks like the link was localized as well
So if I bind the reader using the dashboard, it saves me from some API work, is this correct?
I have sent an email to clarify the restrictions about the country for server side integration
If I get a green light I can start from there and buy the reader
sage fractal
if I bind the reader using the dashboard, it saves me from some API work, is this correct
I don't know what you mean by this
sage fractal
Are you asking about whether you should use the Dashboard or the API to create Reader and Location records?
steel patio
Im asking if I read it correctly, so if I use the dashboard I dont need to write more API code to do the same thing
sage fractal
Yes, those two tabs are showing the two different options to accomplish the same thing
steel patio
Ok all good, Im just waiting for the answer about server side from non US and we are ready 👍
I need to leave, thank you for all the help.
sage fractal
Happy to shed what 💡 I can 🙂