I’ve been reviewing the documentation on in-app payments. In my case I need to accept credit cards in-app. From what I read this will require a custom server component. So I guess I have two questions…
Really?
Why?
I only ask because as it stands my app doesn’t require backend support, and I can’t think of a technical reason to handle it this way.
Thanks!
-Dave-
Hi Dave,
Currently with In-App Payments a server component is required. We do not allow API calls directly from the app. This would expose your API credentials. For additional information please visit Frontend versus Backend.
Hey, Bryan. Thanks. That makes perfect sense.
I suppose that a crypto approach with certificates could provide security directly from the device, but that stuff gets crunchy. Perhaps one day…
Been working thru my back-end server code for in-app payments. My design choice was to do as little on the server as possible. So my client (mobile app) sends over
sourceId
amountMoney
orderId
The server calls paymentsApi.createPayment() and sends the response back to the client. Nothing more.
In working thru the APIs I realize that the only API credential that I use is accessToken. I use that in my app as well, so it would stand to reason (to me) that I should be able to do all that on the client, and this approach doesn’t really provide any additional security. (As the accessToken is required in the app as well).
What am I missing?
Hey @DavidHVernon,
The access token needs be configured on the server side for the CreatePayment request. Your applicationId is the only thing that will be configured on the client side and is what is used to generate the sourceId or nonce. Also it would be a good idea to pass the locationId to the CreatePayment request so the funds go to the correct Square location in your account.
Let me see if I understand this correctly. When I make rest calls from the mobile app, I pass:
‘Authorization’: Bearer ${squareAccessToken},
On the client side squareAccessToken would be my square ApplicationID? Not my square access token? (I’ve been using the Access Token on the client.)
PS. I didn’t mention it, but I am passing the locationID from the client to the server. I create the order on the client, and that order is associated with a location.
Hey @DavidHVernon, all rest calls with the ‘Authorization’: Bearer ${squareAccessToken} will have to happen on the server side. We don’t recommend any client side rest call with the access token.
The ApplicationID is only used for generating the nonce which is then passed to the payment request on the server side as the sourceId.
@Bryan-Square - Still confused. ‘The ApplicationID is only used for generating the nonce’. Does that mean ‘by convention the ApplicationID is only used for generating the nonce’, or that ‘The ApplicationID can only be used for generating the nonce’?
That may not be clear so let me elaborate. In my mobile app I go directly to Square for a few things:
in particular. Are you saying those CAN NOT BE MADE with the Application ID? It that is true, there goes my weekend!
@Bryan-Square - I just went and checked in the API Explorer. sure enough, I’m screwed!
Is it documented anywhere that you can not call Square directly from a mobile device? I sure missed it.
To be very clear here: you can call the APIs from your mobile application, but we strongly recommend that you do not. Doing so means your secret access token will be stored within the application which is a security risk (a bad actor could potentially expose your access token, which means they would have the ability to make API calls to your account). With that said, you would still have to use the access token and not the application id to identify your application for the API requests.
In the In-App Payments SDK “How it works” documentation it says:
- The mobile application sends the nonce returned by In-App Payments SDK and the payment amount to a secure backend service.
- The backend service creates a Payments API CreatePayment request with the provided nonce.
So this is saying we expect you to have a backend service running somewhere, not on your mobile application, to handle the actual API call, that your mobile device can call.
Thanks for the info.