Riverty Payments: Troubleshooting and FAQ
Troubleshooting Riverty Payments for Sylius - missing payment methods, stuck payments, setup errors, uncaptured orders, known limitations, plus FAQ on data, configuration and compatibility
Riverty Payments: Troubleshooting and FAQ
This documentation always describes the latest published version.
For any problem with a call to Riverty, start with the API log: it shows what was sent and answered.
Riverty does not appear at checkout
Symptom: One or all Riverty payment methods are missing in the payment step.
Check:
- Does the channel have an API key for the country of the billing address (with the matching mode, sandbox or live)? The list of settings shows the active countries.
- Does the currency of the order match the country (EUR in Germany, CHF in Switzerland, NOK, SEK, DKK in the Nordics, EUR in Finland)?
- Is the payment method assigned to the channel and enabled?
- For instalments: does Riverty have a plan for this amount? Because the checkout asks Riverty, the instalment method disappears for an amount without a plan. The answer is cached for five minutes.
- Read the notices in the admin above the list of settings, they name the reason.
Solution: Add the key, click Create payment methods, or use Check Riverty contract to see what your contract offers.
The customer is not sent to Riverty, the payment stays "New"
Symptom: After the order the payment stays in the state New and the customer does not end up at Riverty.
Check: Is SYLIUS_MESSENGER_TRANSPORT_PAYMENT_REQUEST_DSN set to a queue (for example Doctrine) instead of sync://?
Solution: Set it to sync://. With a queue, the authorization only runs when a worker consumes it.
The checkout throws an error about an unknown gateway
Symptom: An error (usually a message from Sylius that the gateway does not exist) when choosing or paying with Riverty, although the payment method exists.
Check: Was the payment method created by hand? Sylius starts new payment methods on the Payum model, and there is no Payum factory for Riverty.
Solution: Click Create payment methods. The button switches the Payum model off for the payment method and repairs one where it was set wrong by hand.
None of the API keys work anymore
Symptom: Every call to Riverty fails after the shop was moved or set up again.
Check: Did APP_SECRET change?
Solution: Restore the old APP_SECRET, or enter and save all keys in the admin again.
mmd:riverty:setup aborts
| Message | Cause | Solution |
|---|---|---|
| "Migrations this plugin builds on are still open" | Migrations of Sylius itself are still open | Run doctrine:migrations:migrate first, then the setup command again |
| "The migrations of this plugin are not registered with Doctrine" | Bundle not enabled, or sylius_core.prepend_doctrine_migrations set to false |
Check the bundle in config/bundles.php and do not set the option to false |
| "migrations are written for MySQL 8 / MariaDB only" | A different database, such as PostgreSQL | The plugin needs MySQL or MariaDB |
The menu entry is missing or the admin reports "route not found"
Check: Is the route import from the installation in place? If it is missing, the plugin leaves out the menu entry rather than breaking every admin page, and the setup command prints the snippet.
Solution: Add the import and clear the cache.
A shipped order was not captured
Check:
- Is Capture automatically when the order is shipped enabled for the channel?
- Does the Riverty card say "Automatic capture on shipment failed: ..."? Then the message names the reason, and you can capture by hand.
- Does the order have several shipments? Capture only happens once the last one has shipped.
- Is the reservation over? After 30 days a capture is no longer possible, see Reconciliation and expiry.
- Does your shop use the
symfony_workflowadapter? Withwinzou_state_machinethe feature does not run.
Riverty refuses a partial capture or partial refund
Check: Open the API log and look at the request for this order.
Solution: Whether Riverty accepts a partial request in this form depends on your contract. Test in the sandbox and, when in doubt, capture the whole order.
Known limitations
- Nordics through the Shop API: The identification number cannot be passed in headless mode, and such an order is not sent to Riverty. See Shop API.
- Riverty is the source of truth: The plugin does not notice changes made directly in the Riverty portal. Make all changes in Sylius.
- No webhook: Riverty reports nothing by itself, open payments are reconciled by a cron job.
- Database: MySQL and MariaDB only.
- State machine: Capture on shipment and blocking the Sylius buttons need
symfony_workflow.
FAQ
General
Are payment details stored in the shop?
No. The customer enters them in the hosted checkout at Riverty. The shop holds the transaction, the API keys (encrypted) and the masked API log.
What data do I see in the API log?
Requests and responses with personal data masked. The API key is never stored.
Configuration
Can I use different keys per channel?
Yes, the settings apply per channel.
Can I mix test and live?
Yes, the sandbox can be switched per country.
Compatibility
Does the plugin run with Sylius 2.1?
It requires sylius/sylius ^2.2 and is tested with 2.2 and 2.3.