Introduction
⚠️ Warning: This documentation is currently published as DRAFT. Some sections may be incomplete, and we prefer to only publish them when finalized. We will log documentation updates in the Release Notes (Last update: 25/02/2026)
25 February 2026
Concept
Payperpot is a cloud-based payment solution that allows a Point of Sale (POS) system to communicate with payment terminals via web services. This documentation provides an overview of the Paypercloud API, its components, and how to set up and use the system effectively.
A remotePos (remote Point of Sale) is an external device, from our system point of view. It will only send requests to our devices, it will be referred as the source of the request.
The terminal is called pos (historically), but within the paypercloud scope, it is only acting as a Pop (Point of payment). It will be referred as the target of the request.
Both remotePos and Pop are identified by a PID (Paypuce Identifier : 12 Hexadecimal digits). Respectively, the sourcePid and targetPid.
A RemoteAction is a “request” that a source can send to a target, always identified by its UUID. It was previously called an “Operation” but to avoid confusion with the actual payment operations (purchase, refund, void, etc) we renamed it to RemoteAction.
The target retrieves a remoteAction created by the source, changes its status, processes the request using the payment application, saves the result with the request, and transmits it to the paypercloud backoffice while changing the status to PROCESSED.
More details about the workflow can be found in the Flow section.
GoTo Production requirements
Authentication, Purchase and Closing integrations are strictly required.
Void and Refund are optional, but highly recommended (at least for your testing phase).