13. SavaPage Plug-ins

Table of Contents

• 13.1. Web API Callback Plug-in

• 13.2. OAuth Client Plug-in

• 13.3. Mail Print IMAP OAuth Plug-in

• 13.4. Notification Plug-in

• 13.5. IPP Routing Plug-in

• 13.6. User Source Plug-ins

A plug-in (aka “extension”) is a software component that adds a specific feature to SavaPage. Plug-ins have a well-defined interface so partner developers can easily create isolated components that extend the application with new features. Extension interfaces are defined in the savapage-ext project.

A plug-in is installed by copying its property file in /opt/savapage/server/ext and its jar files in the /opt/savapage/server/ext/lib directory. For example, the Mollie Payment Plug-in is installed with these two files:

/opt/savapage/server/ext/savapage-ext-mollie.properties
/opt/savapage/server/ext/lib/savapage-ext-mollie-<version>.jar

Important

Since property files contain sensitive data make sure they are protected by executing commands like:

sudo chown savapage:savapage savapage-ext-mollie.properties
sudo chmod 600 savapage-ext-mollie.properties

13.1. Web API Callback Plug-in

The Web API Callback method is used by many third-party providers who offer their services via HTTP. SavaPage supports this method with the /callback URL path. However, URL protocol and authority for the callback needs to be configured. Configuration is done by using the Config Editor of the Admin Web App. The following configuration property is available:

Web API Callback Configuration Property

Configuration property

Description

ext.webapi.callback.url-base

The publicly accessible base URL, i.e. protocol://authority without the path, of the Web API callback interface (no trailing slash). If SavaPage is implemented as intranet application to be accessed with a local URL, take care to configure proper port forwarding of the public base URL to the local SavaPage server host name or IP address in your router or firewall. Important: use https protocol, and make sure the SSL Certificate for public access is valid, i.e. not self-signed. When the certificate is invalid, a third-party service provider might not be able to deliver call-back messages.

13.1.1. Payment Gateway Plug-in

The Payment Gateway Plug-in is based on the Web API Callback Plug-in and uses the /callback/payment URL path. The following configuration property can be set by using the Config Editor of the Admin Web App.

Payment Gateway Configuration Property

Configuration property	Description
ext.webapi.redirect.url-webapp-user	The User Web App URL used by the Web API to redirect to after a remote Web App dialog is finished. Configuration is optional. SavaPage uses the local URL from which the remote excursion started as default.

Payment Gateway events are persisted in the rotating log file: /opt/savapage/server/logs/paymentgateway.log

This file has a tab separated value (TSV) format for easy import and manipulation into spreadsheet programs.

13.1.1.1. Generic Payment Plug-in

A Generic Payment Plug-in implements several payment methods behind a single Web API. Only one generic plug-in can be active. See Financial, Transfer Money and Payment Web App.

13.1.1.1.1. Mollie Payment Plug-in

Mollie is a Dutch payment provider that offers a single Web API for various payment methods, including:

• Creditcard

• PayPal

• paysafecard

• SOFORT Banking (Europe)

• SEPA bank transfers (Europe)

• Bancontact/Mister Cash (Belgium)

• Belfius Direct Net (Belgium)

• iDEAL | Wero (Netherlands).

Mollie supports the European Economic Area and Switzerland and accepts EUR payments only.

See the README.md of the savapage-ext-mollie project for more information.

Note

The Mollie Payment Plug-in is shipped with the SavaPage install binary.

13.1.1.1.2. Generic Payment Pitfalls

Callback messages for generic payments return the identity of the user that started the payment in the Transfer Money dialog. So, when a payment is acknowledged, we can easily add the amount paid to the user’s balance. In some very unlikely cases a user might not be found. For example, when a database export is restored or a user was deleted, all in the short lifecycle of a payment transaction.

In the rare case a user is not found, a warning message containing the user and transaction identification are written to the Application Log. With this information the user balance can be updated manually, after the user has been added again, either in the Admin WebApp or with a Server Command.