PayPal POS for WooCommerce

Connect your WooCommerce store to PayPal POS (Point of Sale) and keep your products and stock in sync across both. Manage your catalog in WooCommerce, push it to your PayPal POS product library, and let stock levels stay accurate on both sides as sales come in.

Installation

The best way to use this package is through Composer:

$ composer require inpsyde/paypal-point-of-sale

Requirements

• PHP >= 8.2
• WordPress >= 6.8
• WooCommerce >= 10.2

Development

0. Install Docker and DDEV. Edit the configuration in the .ddev/config.yml file if needed.
1. Get your packagist token, copy/hardlink your Composer auth.json (from ~/.config/composer/auth.json or ~/.composer/auth.json) to ~/.ddev/homeadditions/.composer/auth.json
2. Run make setup to set up DDEV and install dependencies. Go to https://paypal-point-of-sale.ddev.site
3. Run make lint test to run the linter and tests.

Use make reset for reinstallation (will destroy all site data). You may also need make restart to apply the config changes.

See Makefile for other useful commands.

For Windows users: make is not included out-of-the-box, but you can simply copy the commands from Makefile to cmd, e.g. ddev exec phpcs, ddev exec phpstan analyze instead of make lint.

Webhooks

For testing webhooks locally, follow these steps to set up ngrok:

0. Install ngrok.

1. Run our wrapper Bash script, which will start ddev share and replace the URLs in the WP database:

   make ngrok

For other environments, you can instead run ngrok http -host-header=rewrite paypal-point-of-sale.myhost and set the NGROK_HOST env variable to the host that you got from ngrok, like abcd1234.ngrok.io. In this case, ngrok will be used only for the webhook listening URL (paypal-pos.webhook.listener.url service). The URLs displayed on the WordPress pages, used in redirects, etc. will still remain local.

Tests

Set the API key in .env.phpunit and run this to execute all tests in all modules:

make test

You can also run

vendor/bin/phpunit

to execute tests only in a single module (after cd to its directory inside modules.local), or to execute only integration/acceptance tests in the repository root.

Linter

Run this to execute PHP_CodeSniffer and PHPStan, checking code style and quality in all modules:

make lint

You can also run

../../vendor/bin/phpcs .

to execute it only in a single module (after cd to its directory inside modules.local).

Publishing to WordPress.org

Releases are published via the Publish to WordPress.org GitHub Action, which wraps inpsyde/reusable-workflows' wordpress-org-release.yml.

Trigger it manually (workflow_dispatch) with:

• PLUGIN_VERSION — the version to publish, as MAJOR.MINOR.PATCH. Must match both the Version: header in zettle-pos-integration.php and the Stable tag in readme.txt.
• GIT_REF — the build branch or tag to publish, e.g. main. This must be a build branch (created by the Build workflow, dev/main → main), never a dev/* source branch — those still carry a {VERSION} placeholder instead of a real version number, and the workflow will refuse to run against one.
• UPDATE_TRUNK_ONLY — when true (default), only SVN trunk is updated; set to false to also cut a new SVN tag.

Crafted by Syde

The team at Syde is engineering the Web since 2006.

License

Copyright (c) 2025 Syde

Good news, this plugin is free for everyone! Since it's released under the GPL-2.0 License you can use it free of charge on your personal or commercial website.

Contributing

All feedback / bug reports / pull requests are welcome.