Deutsche Version

Back to overview

Riverty Payments: Reconciliation and Expiry

This documentation always describes the latest published version.

Reconciling open payments

Riverty sends no webhook. A customer who pays at Riverty and then closes the browser never comes back to the shop, so the Sylius payment would stay open although Riverty holds an accepted order. The command mmd:riverty:reconcile finds these payments and asks Riverty about them. Run it from a cron job:

*/10 * * * * cd /path/to/shop && bin/console mmd:riverty:reconcile

What the command does

For every Riverty transaction that is still pending and whose payment is still open (new or processing):

What it does not do: it never touches a transaction that is already authorized, captured, voided or refunded, it does not capture or refund anything, and it does not cancel orders.

Options

The output is a table with the Riverty reference, the order number, the outcome and the payment state, plus a summary line. The exit code is 1 only when every attempted transaction failed unexpectedly.

Expiring authorizations

Riverty cancels an authorization by itself 30 days after it was made and tells the merchant nothing. A shipped order that was never captured is then not paid by Riverty, and once the reservation is over, capturing is impossible. The plugin watches for this.

graph TD
    A["Authorization granted"] --> B["Plugin notes creation time plus 30 days"]
    B --> C{"Warning window reached?"}
    C -->|No| D["Nothing"]
    C -->|Yes| E["Note on the order page and entry in the digest mail"]
    E --> F{"Does Riverty report the end?"}
    F -->|No| G["Reservation stays"]
    F -->|Yes| H["Transaction Authorization expired, payment cancelled"]

• The end of a reservation is computed from the moment the plugin created the Riverty transaction plus 30 days (Riverty reports no end date). It is shown on the order page in the Riverty card.
• The order page says what applies: how long Riverty holds the reservation, that it ends soon, that a shipped order is not captured yet or only in part (capture the rest now), that the reservation is over and can no longer be captured, or that a shipped order lost its reservation.
• mmd:riverty:reconcile asks Riverty about every authorization past its 30 days. Only an explicit answer of Riverty ends a reservation (status Expired, Cancelled, Canceled or Voided): the transaction becomes "Authorization expired" and the payment is cancelled. The order itself is not touched, you decide what becomes of it. A reservation that Riverty still holds stays as it is, and a status the plugin does not know changes nothing but shows up in the digest.
• The warning window is set per channel on the settings page ("Warn before an authorization ends", 1 to 25 days, default 5).

The daily digest mail

The mail goes to the contact email of the channel (set it in the channel settings; the settings page warns when it is missing), in the default language of the channel, at most once a day and only when there is something to report. The sender is the Sylius mailer sender address.

Order of the entries:

1. shipped orders that were not captured
2. reservations Riverty cancelled (reported once)
3. reservations that end within the warning window
4. unknown answers of Riverty

An order appears once, under the most urgent heading. The mail links to the orders only when the channel has a hostname, and the links use https.

mmd:riverty:reconcile --no-digest skips the mail; --dry-run asks Riverty but changes and sends nothing.