Skip to main content
Version: 3.2

Release Notes

Documentation​

  • 2026-03-25 :
    • Added webhook feature.
    • fixed minor bugs related to cashless.
  • 2026-02-25 :
    • Fixed typo in ´Transition a remote-action: cancel´ route. #cancel-action.
    • updated Backoffice section
    • added Glossary section to explain the new terminology (draft)
    • added enum numeric values in Flow for Statuses.
  • 2026-02-11 : Release of first public draft of this documentation.
  • until 2026: PDF Documentation provided by email.

Application​

3.2 — Cashless payment (2026-01)​

Important changes in this release:

  • API naming: all new fields use camelCase. Existing snake_case fields are deprecated but will continue to be accepted until a future update.

  • Terminology changes to reduce ambiguity:

    • pos is now referred to as source (the entity that triggers actions).
    • Terminal is now referred to as target.
    • Both source and target are identified by a PID (PaypuceIdentifier): a string of length 12 (hex).
  • Actions and operations:

    • The previous use of the term "Operation" referred inconsistently to different entities. To clarify, we now use the term (remote)Action for the entity sent from a source to a target.
    • A (remote)Action can result in an operation (for example: purchase, refund, preauth) or can lead to another entity (for example: closing, message, reset, setup).
  • Purchase / Refund / PreAuth changes:

    • terminalPrint changed from string to int and has been renamed to shouldPrintReceipt.
    • allowedPaymentMethodIds parameter was added to enable payments with gift cards.
    • A webhook parameter was added to allow a callback once the action has been processed.
  • Cashless features (PayPerCloud compatibility):

    • New route to top up a cashless card.
    • New route to retrieve a cashless card balance.
    • New route to list all terminals reachable by a POS.

3.1.1 — Token expiration (2025-11)​

Security improvements change the token model:

  • Prior to v3.2, tokens were issued with no expiration. Starting with this release we require two tokens:

    1. secret_token — generated from the back office. Validity: 365 days. This token can only be used with the Get Access token endpoint .
    2. access_token — obtained by calling Get Access token. Validity: 7 days. Only access_token can be used for business endpoints (e.g. purchase, refund, void).
  • Migration note: groups created before 2025-11-01 had tokens without expiration. A default 1-year expiration has been applied to those existing tokens.


3.1 — PID as the unique identifier​

  • Before v3.1, the pid only identified the terminal. From v3.1 onwards both the POS and the terminal have a PID (Paypuce identifier) and are referenced as:

    • posPid (for the POS)
    • terminalPid (for the terminal)
  • posid is deprecated and replaced by posPid. The API will accept both posid and posPid for backward compatibility until May 2026.

  • To avoid ambiguity the pid key in requests has been renamed to terminalPid. The API will accept pid and terminalPid until the pid alias is removed in a future deprecation.

3.0 - Initial PayPerCloud release (2024-12)​

  • Initial release of PayPerCloud API v3.
  • Supports basic operations: purchase, refund, void, reconciliation.
  • Authentication via Sanctum tokens.
  • Group and user management.
  • Terminal and POS management.
  • Detailed logging of operations.
  • Extensive error handling and status codes.

2.0 - Initial PayPerCloud release (2024-06)​

  • Initial release of PayPerCloud API v2.
  • Supports basic operations: purchase, refund, void.

1.0 - Initial PayPerCloud release (2024-01)​

  • Initial release of PayPerCloud API v1. (POC version)