Live Demo: Try this and other plugins live — no installation, no risk: demo.markus-michalski.net
This page describes which personal data the module processes. It is not legal advice. As the shop operator you are responsible for your privacy policy and your contracts with Riverty.
The module sends data to the Riverty API (sandbox: https://api.bnpl-pt.riverty.io, live: https://api.bnpl.riverty.io). Requests originate from the shop server, depending on the country with its API key.
When the payment selection is opened, only country, currency, net and gross amount and the language are sent to Riverty. No customer data is transmitted.
When an order is completed with a Riverty payment method, the following data is sent:
| Area | Data |
|---|---|
| Customer | First name, last name, email, salutation, billing address incl. address addition |
| Optional, if present in the customer account | Phone, mobile phone, date of birth, customer number, company name, VAT ID |
| Nordics (NO, SE, DK, FI) | Identification number or company registration number that the customer enters at checkout |
| Delivery address | Name, address, country, phone (alternative delivery address or billing address) |
| Order | Order reference, items with prices, amounts, currency, return URL of the shop |
| Risk data | Customer IP address (always), existing-customer data depending on the setting |
| Language | Shop language for Riverty's communication |
Payment details such as account number or card data are entered by the customer at Riverty, not in the shop.
The setting "Send existing-customer data to Riverty" controls the additional risk data:
| Mode | Additionally transmitted |
|---|---|
| Disabled (default) | nothing, only the IP address |
| Flag only | whether the customer already has a successful order |
| Full | additionally the date of the first successful order, the number of successful orders, the total order amount of the last 12 months |
The "Flag only" and "Full" modes transmit data from the order history. Clarify the GDPR/DPA basis with your legal counsel before enabling. If the order history cannot be read, the module sends no existing-customer data for that order and the checkout continues.
Capture, void, refund and status queries use the order reference, items and amounts. Capture, void and refund calls can also be triggered via the Integration API.
| Location | Content | Retention |
|---|---|---|
Table mmd_riverty_transactions |
Order reference, payment type, country, status, amounts, capture/reservation numbers, captured/voided/refunded items, last API response, error message | Rows with a linked order are kept. oe:riverty:cleanup deletes abandoned payment attempts without an order after the configured period |
Table mmd_riverty_api_logs |
Request and response of every API call, status code, duration, country. Personal fields (name, email, address, phone, date of birth, identification number, company name, VAT ID, customer number, IP address) are masked except for the last four characters | Default 90 days, configurable, deleted by oe:riverty:cleanup |
Table mmd_riverty_idempotency_keys |
Integration API idempotency keys and the cached response | Same as the API logs |
File riverty.log |
Only with debug logging enabled: process log, personal fields masked | No automatic deletion |
| Session (redirect) | During the redirect to Riverty: basket, reservation ID, order reference and country code | Removed after the return |
| Session (identification number) | With a billing address in NO, SE, DK, FI the identification number entered at checkout (dynvalue[identificationNumber] in the OXID session) |
Not part of the basket backup and not removed by the module, it ends with the OXID session |
The retention periods only apply if the
oe:riverty:cleanupcron job is set up. Without the cron job the data stays.
https://my.riverty.com.