Since our product needs to identify the POS order from other type of orders. I got the solution that Payment API’s attribute square_product has a stable value: SQUARE_POS from this thread: The source field of an POS order has been changed. Then we changed the our Square integration product’s logics to rely on this value.
"application_details": {
"square_product": "SQUARE_POS"
However, today we just got lots of reports from our merchant clients and we figured out that it’s causes by the unexpected change on application_details.square_product. Some payments made on Square POS still remain the value: SQUARE_POS while some have been changed to the OTHER without any notification. We want to know whether it’s a bug or not?
Do you have an example payment_id that you noticed the change? 
JwmkUXWyAG3QY6bnFCY2zJ3HuaB
ZCfs9IOYx0YZdOw6HM975rWGvaB
Any update on this issue?
What’s happened here is that your examples are from Restaurants. The ones from SQUARE_POS are working as expected. The team is working on a deployment that will better identify the Square product. So the examples you provided will say RESTAURANTS.
The key point is, can we get notified prior to deploying those changes, our product relies strongly on this product type, we talked it before in another ticket, and we expect this one to be stable. In addition, I think those examples were from SQUARE_POS since they were handled correctly in the past year.
The key point is, can we get notified prior to deploying those changes, our product relies strongly on this product type, we talked it before in another ticket, and we expect this one to be stable. In addition, I think those examples were from SQUARE_POS since they were handled correctly in the past year.
Those examples are definitely from RESTAURANTS. At this time we don’t have public roadmaps or notifications to subscribe to for features and product releases. We’re constantly working to improve our features based on feedback like this, so I’ll be sure to share your request to the API product team.