- The Adyen sync cron didn't call the function to sync terminals
- Do not specify the merchantAccount when creating a store, the proxy
will add it itself.
closesodoo/odoo#59868
X-original-commit: d5b456a1f75320c8fdf1e989afad91fc74ec9ef3
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The goal is to add a nice payment solution to our users.
- Why Adyen?
- Worldwide
- Manages local payment solutions
- Easy onboarding
- For both PoS and eCommerce
- Why Adyen for Platforms?
- The onboarding will be done directly from the customer's DB.
- It's quite complicated for SMEs to get a partnership with Adyen as
they have high requirements for transaction volume. By registering
Odoo as a Platform with Adyen Marketpay, we allow our users to
register as sub-merchants under a common account, removing this
constraint.
As all users are grouped under a common account, all requests need to
provide the same API key. As this key cannot be shared, all requests to
the Adyen API will need to be proxied. A new proxy will be created on
`paymentproxy.odoo.com`.
To initiate a payment, 3 values are required:
- `account_holder_code`: This code is provided by Adyen and is used to
identify the sub-merchant under the common account.
- `adyen_uuid`: This ID is used internally to identify the user.
- `proxy_token`: This token is generated by the proxy during the
account creation and is used to sign all requests.
The DB of the customer is the only host who has all the information
required to modify the sub-merchant info or initiate a payment. If
this information leak, the `proxy_token` can be reset on the proxy to
revoke all access to the API.
Before accessing the form to create an account, users will be
redirected to www.odoo.com where they will be asked to log in. This
ensures that we have contact information for this sub-merchant.
TaskID: 2129218
Revert commit e6372c3, the concurrent updates were solved by the change
in the order of the lines, not by the fact that functions were defined
as api.model
As long as the payment is not validated, the cashier can add products
to the order, even if the payment has been completed. The amount
authorized can be adjusted if the payment interface implements the
canBeAdjusted method.
closesodoo/odoo#56656
Taskid: 2117032
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The amount is authorized when the customer scans its card, then the
customer writes the tip on the receipt and the total amount is captured
when the waiter manually inputs the tip, either right after or at the
end of the day.
closesodoo/odoo#56148
Taskid: 2321771
Related: odoo/upgrade#1661
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Disqualify the constraint in the adyen identifier if it is empty because
it is not needed in other payment methods that are configured with other
payment terminal.
closesodoo/odoo#36702
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
For now when you are using payment terminals in the point of sale, you
have different way to configure payment temrminals, for the IOT, you
have to select the payment terminal in the pos config, and for adyen and
ventiv you have to configure them in the payment method.
So we've modified it to always configure payment terminal on payment
mehthod, and not on the pos config anymore, with iot you'll be able to
select the specific device you want to use, even if it is not on the iot
box set on the pos config.
closesodoo/odoo#35665
Task-id: 2042382
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Every time we check the status of a request (every 3 seconds) we also
launch another request to check the status of the terminal. This way
we can notify the user if the terminal is no longer reachable.
Even though we call Adyen's async endpoint for this it can still take
a while to complete (>2 seconds). Before this change the
pos_payment_table would be locked for this entire duration. This means
it's now likely that during this time Adyen calls us back to say the
transaction is finished. It needs to write on the payment method which
causes the concurrent update error.
Odoo's automatic retry mechanism would usually handle this fine but
it's not pretty solution.
Instead let's convert the methods that do the async call to @api.model
functions and pass in all the data they need. This solves the problem
because now we won't need to lock pos_payment_method for the duration
of the request.
This allows Adyen's POS terminals to be used in the POS. The
architecture is as follows:
Odoo <--> Adyen server <--> Adyen payment terminal
It means we don't have to communicate directly with the
terminal. Instead we send HTTP requests to Adyen's API and they take
care of the rest. Therefore this integration doesn't require an
IOTBox.
Unfortunately this module is more complicated than it needed to be due
to Adyen's API not supporting CORS. Because of this we can't directly
call their API from JS. Instead we need to proxy requests through the
Odoo backend. This complicates things further because this means we
can't use their synchronous API. With this API an HTTP request remains
open for the entire duration of a transaction. We can't afford to
block an HTTP worker this long. So this implements their asynchronous
API which calls us back when a transaction completes.
In addition to the regular sale requests we also poll the status of
the terminal using DiagnosisRequests while transactions are in
progress. This is to handle cases where a payment terminal loses
connection after a payment transaction is initiated. It also handles
cases where a terminal was recently disconnected (<1 min). In this
last case Adyen will process the payment request as usual, without
notifying us the terminal is offline. It's important to notify the POS
user to check the terminal, otherwise he'll have no idea something is
wrong. We store the DiagnosisResponse's unique ID and every time the
POS requests a status update we launch a new DiagnosisRequest. When we
no longer receive DiagnosisResponse ID updates we can notify the user
of this in the POS.
To test this locally use something like ngrok so Adyen can call you
back.
API docs: https://docs.adyen.com/point-of-salehttps://www.odoo.com/web#id=1981799&model=project.task&view_type=form&menu_id=
Martin Trigaux