Theo VINCENT (thvi)
3fa87c8c47
*: point_of_sale, pos_adyen, pos_hr, pos_mercury, pos_restaurant Adds online payments in Point of Sale using the payment module. The pos_online_payment module is meant to be used by shops for paying online instead of using a physical terminal and by restaurants for paying an order either from the paying station or in the self-order process (smartphone used to order and pay online). The module depends only on point_of_sale (and account_payment to support online payments). The online payments support for self-order will be added in another commit. The feature can be used by configuring a special pos.payment.method for one or many pos.config. Operation: The frontend session user can enter one or several online payment method lines (with or without other payment methods). When he validates the order, if the online payment amounts are valid, a popup with a QR code is displayed on the frontend screen and on the customer display. This QR code allows the customer to open the payment page to pay online for the order. The amount to pay for an order on the payment portal is the remaining unpaid amount or a lower amount if several online payments lines are used. Therefore, at any time, the customer will be able to pay the amount of the order that is unpaid, without requiring a staff operation to update the amount to pay. When an online payment is done for a POS order, the generated account.payment is linked to the POS order through a pos.payment that is created with the online payment method configured for the pos.config, and the POS order paid process is triggered (it is the responsibility of the server to finalize the validation of POS orders that have at least one online payment, and not the responsibility of the POS session web client). If for any reason, there is no longer any online payment method configured for the pos.config of the order, a new one can be created automatically and exceptionnaly used to link the done payment with the POS order. This guarantees that any online payment saved by the payment module will be linked to the POS order. The session web client is notified of successful online payments through web socket communication, to make the cashier screen automatically and quickly react to payments. If several online payments are used for a single POS order, they are processed one after each other. Working principles: - The POS session web client is not allowed to save online payments on the server. Only the Odoo server, which handles the payment, can save online payments for a POS order. - The POS session is only responsible for saving the order (especially other payment methods) and the next online payment amount to pay (in case of several online payments) on the server before the online payments are made by the customer, and for displaying the online payment status and the link (QR code) to open the payment page. That means that modifications that are made after the order is fully paid are not taken into account by the server. - Before validating an order, the POS session checks with the server if any online payment has been made for that POS order. If the user wasn't aware of one, the validation process is aborted, notifying him. - The sensitive online payments data is received by the frontend user with RPC to the server when validating an order, cancelling an online payment or receiving a notification through the POS bus (web socket communication). This data is used to update the cashier data for the specific order. - No sensitive information is sent through the POS bus (web socket communication). Indeed, the bus communication is only protected by the name of the channel, and there is no mecanism to prevent several attempts. Therefore, no sensitive information is sent through it, only a notification to invite the local browser to do a safe RPC to the server to check the new state of the order. - Online payments for a POS order cannot be modified or removed when they succeeded. Checks ensure to never allow an online payment to make the total paid amount greater than the total amount of the POS order. - If the frontend user clicks on the "Cancel" button of the online payment popup, the order can potentially still be paid online. Indeed, the order will be removed from the server only if it was added only for the online payment flow, and any order that is not paid can be paid on the online payment portal (if the customer has the web link). This behavior ensures that in a shop, starting an online payment and then cancelling it doesn't prevent the user to close the POS session. And it ensures to don't delete a draft order that is used for other flows, like in a restaurant or when there are trusted POS configs. Payment portal features: - The payment portal pages of a POS order are protected with its access_token. - If the amount of the order has changed when the customer clicks to pay, an error is fired to notify him and give him the choice to continue or abandon the payment. - An exit_route argument (an URL) can be passed to allow the customer to exit the payment portal at any time (with a button), which could be used for self-order flow. - A button to go back to the payment page is displayed when an error occurs during a payment transaction, which allows the customer to retry a payment without needing to scan again the QR code. - If the customer is not logged in in the payment portal (most frequent case), it is considered as the public user partner for the payment flow to don't give him privileged access to sensitive data like payment tokens. - The accounting process of online payments for POS orders is made in the same way that the pos.payment.method that have split_transactions to True. - The POS customer of a POS order has no link with the customer making an online payment for that POS order. - The payment portal is made using the pos.order id and not the pos_reference because the latter is not guaranteed to be unique. Some tests have been written, especially one that simulates a whole online payment flow starting from nothing, creating an order, requesting an online payment, faking this online payment by doing web requests to the payment portal, then finally closing the POS session to check that there is no accounting issue. The design of the payment portal is temporary. closes odoo/odoo#123237 Task-id: 3276404 Related: odoo/enterprise#41776 Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
5 lines
129 B
Python
5 lines
129 B
Python
# -*- coding: utf-8 -*-
|
|
# Part of Odoo. See LICENSE file for full copyright and licensing details.
|
|
|
|
from . import payment_portal
|