Point of Sale API - Integration With Catalog

Questions
,
1

In your documentation you state:

Product components

A complete mobile POS integration solution is comprised of a mobile device, a Square card reader, mobile device logic, and a backend service that uses the Catalog API to get items and services for purchase.

Mobile frontend

A mobile application uses the Point of Sale API to create a charge request, start a transaction, open the POS UI, and parse transaction results. The Point of Sale API takes care of transmitting a payment to Square for crediting to a Square account.

A charge request includes a payment total that can be arbitrary or derived from the unit price of a catalog item or service.

Mobile backend

A mobile application should have a backend process to connect to the product catalog defined for the Square account. The backend provides catalog items and services to the mobile device so that the device can show descriptions and unit prices.

A mobile backend isn’t required if the mobile application doesn’t display the product catalog in a Square account.

This leads me to believe that I have the option to construct a payload based on catalog API data, ie passing some catalog object maybe via IDs, and open the Square POS app from my mobile app to let the user checkout in the Square app based on an array of catalog object IDs?

However, when looking at that integration payload documentation for example on iOS, I don’t see a payload option for leveraging such catalog objects, all I see along these lines would be amount.

So when the earlier documentation says A charge request includes a payment total that can be arbitrary or derived from the unit price of a catalog item or service. by derived from does that just mean I would have to calculate the price based off catalog api requests, and then add that up and then pass that as the amount? Or is there a more direct way?

While using amount would work, wouldn’t this mean that downstream of this transaction, such as in data reporting, .etc that Square would not know what was transacted on, even if a catalog was used to create the amount? If that is the case, is there an API based remedy that would not duplicate the transaction?

Just seeking clarification as I’m hoping that I can pass along and leverage catalog items - instead of just an amount number. Or if not, that I can somehow report to Square what was transacted on - especially if that transaction is derived from its own catalog…

2

:wave: I’m Square Dev AI, here to help answer your question!
Based on the information you’ve provided, the following documentation will help answer your question:

Additional Documentation

Point of Sale API and POS Integration Tools
Square Developer Documentation
Square Developer

If this documentation helped you find a solution, please check the box indicating that this reply solves the problem.
Otherwise one of our Developer Advocates will provide additional assistance shortly.

3

The Point of Sale API currently only supports passing a total amount for the transaction. It does not support passing itemized details or catalog object IDs directly in the charge request. The total amount can indeed be arbitrary or derived from the unit price of a catalog item or service, but this calculation would need to be done in your application before making the charge request.

When the documentation mentions “derived from”, it means that your application would need to fetch the relevant catalog object data using the Catalog API, calculate the total amount for the items being purchased, and then pass that total amount in the charge request to the Point of Sale API.

You’re correct that this means Square would not have itemized details for the transaction. If you need Square to have this information for reporting purposes, you would need to use the Orders API to create an order with the itemized details, and then use the Point of Sale API to charge for that order. This would not duplicate the transaction, but would allow Square to have a record of the itemized details of the transaction.

This answer was reviewed by @Bryan-Square.