Before 660dc0ebaf it was possible to use Authorize to pay via your bank
account using the "Redirection to payment acquirer" option. Since the
refactor removed the redirect it was no longer possible. This commit
reintroduces that feature.
It does so by adding new form elements that accept bank account
information. Additionally it reintroduces the `billTo` and `customer`
parameters that Authorize requires when processing ACH payments.
task-2628318
closesodoo/odoo#75289
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Following the recent reorganisation of the documentation in 12.0+,
the majority of the documents have been moved and their old links are no longer valid.
Some redirection rules will soon be deployed, but those rules might be dropped in some years
and we want the links to still work, which is why we still replace the links to the new ones.
FW-Port of odoo/odoo#70675 (13.0)
closesodoo/odoo#70920
X-original-commit: bc9c1eef538ba6095e74c19d5d9ed9e01625ec7c
Related: odoo/enterprise#18361
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit also drops the payment with redirection flow in favor of
the direct payment flow only, while preserving the currently used APIs.
See the merge commit for more details.
task-2333030
Co-authored-by: Adrien Horgnies <aho@odoo.com>
Replace website_published and environment by a generic state on
payment.acquirer
Payment acquirers aren't enabled by default. When setting their state to 'enabled' or 'test', it is verified the required fields for the provider are set.
add accept js of authorize.net to make s2s flow pci compliance
after clicking on pay now button, one popup display with card inputs
popup is provided by a authorize with all validation facilities
After submitting details, payment flow is
- get the temp token information from authorize
- create a token with that temp token information in odoo
- make a request to authorize for charge
- after successful request, payment will be charged for that card
task- 2025821
This commit extends the changes introduced by 88de93114 to adapt
Odoo payment flows to the switch in transaction signature done
by Authorize.net.
The initial fix was not sufficient for flows that mixed redirection
payment flows and server-to-server flows (e.g. paying a quote with a
card that gets saved then using the token to pay for a subscription).
The problem comes from the fact that the server-to-server API uses
the API Transaction Key and API Login ID as credentials to authenticate
requests; there is no need for a signature since this data is never
publicly exposed on the website and a MITM is mitigated by the fact
that it would need to be done between the Odoo server and the
Authorize.net servers (both of which use https in a normal deployment)
which is admitedly more complex than doing a MITM on a Starbucks wifi.
On the other hand, the 'redirection' flow will include all transaction
parameters as inputs in an html form, therefore the signature is
required to ensure that the values have not been modified by a website
user or a mitm.
Since both flows can coexist on the same configuration, we cannot use
the same field depending on the payment flow configuration - we need
both fields to be stored for the provider.
This commit therefore has to introduce new fields on payment.acquirer
record that can store the signature key for authorize in addition to the
usual authorize fields. Instead of adding a new module, this commit uses
non-stored computed fields that will generate System Parameters entries
for any acquirer of the 'authorize' kind when set through the interface.
closesodoo/odoo#34670
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Victor Feyens