Before this commit, the payment providers (e.g., Stripe, Adyen...)
available for payment were displayed on the payment forms. The customer
had to select one to process their payment. After that, the customer had
to select their preferred payment method (e.g., Credit Card,
Bancontact...) from a list of payment methods supported by the selected
provider over which the website administrator had close to no control.
This was making the payment forms confusing because the payment methods
were displayed sometimes more than once, if at all, in a non-controlled
order, and behind the selection of a payment provider that customers
should not have to deal with.
As the payment method was selected in an iframe or directly on the
provider's website, the information on the selection payment method was
not available in Odoo. This posed many problems, among which were the
impossibility of assessing whether a specific feature (e.g.,
tokenization, refunds, manual capture...) was available, not being able
to easily identify payment tokens through the payment method logo,
listing available payment methods on the website, sorting and
fine-grained configuration of the available payment method, subpar
payment method-specific display on the payment form (e.g., PayPal that
requires displaying a "Pay with PayPal" button), etc.
In this commit, the payment providers are thus replaced by the payment
methods on the payment forms. All contextually available (depending on
the country, currency, requested feature...) payment methods are
displayed one after the other on a single-level list and in the order
configured by the website administrator. Each payment method is
"powered by" (i.e., linked) to a single payment provider: the first one,
by model order, to support it. This allows, for example, offering the
PayPal payment method through Mollie, which charges low processing fees,
while also offering Klarna through Stripe, which supports more payment
methods but charges higher processing fees.
While doing so, the two different payment forms, "Checkout" and
"Manage", are also merged together in a new, configurable case-by-case,
payment form that is entirely redesigned to offer a better user
experience.
After payment, the information on the selected payment method is saved
on the transaction and eventual payment record and updated with the
information received from the provider.
task-2882677
closesodoo/odoo#120446
Related: odoo/upgrade#5103
Related: odoo/documentation#5717
Related: odoo/enterprise#40666
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Anita (anko) <anko@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Valeriya (vchu) <vchu@odoo.com>
avoid overriding payment views by creating new computed field in the payment provider property and override it if needed in inherited payment models
task-3120983
closesodoo/odoo#116573
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Issue:
Merchant account created inside Philippine will use PesoPay,
created inside Thailand will use SiamPay, and created inside
Indonesia will use BimoPay. Currently. only PayDollar is
available.
Cause:
Missing PesoPay, SiamPay and BimoPay.
Solution:
Add a brand setting on payment provider to allow user to select
which branch will be used.
More:
- What is PayDollar, PesoPay, etc. to AsiaPay?
PayDollar, PesoPay, SiamPay, BimoPay is the same system under AsiaPay
but is for different countries to apply.
PesoPay is for the PH market
SiamPay is for the TH market
BimoPay is for the ID market
while PayDollar is for all other market likes HK, CN, MO, TW, SG, MY,
IN, VN, NZ and AU
- Why are there multiple endpoints for a given API?
Below reasons are from AsiaPay side
Local regulators requirements for BimoPay
Branding purposes to localize for the users for PesoPay and SiamPay.
- Why didn't we integrate all these endpoints in the first version of
our AsiaPay implementation?
We got in touch with AsiaPay after our first integration. Therefore
after partnership established with AsiaPay, they provide more
integration guides on the whole development
- If many customers ask for these endpoints?
Right now, there is no customers asking for these endpoints. However
if they register AsiaPay under certain countries, they have to use
the other endpoints otherwise they will not able to use AsiaPay on Odoo at all.
task-3073748
closesodoo/odoo#110357
Related: odoo/documentation#3423
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, the lists of supported currencies by payment
provider were hard-coded in the Python scripts, which made them
unavailable to the users.
With this commit, the implemented initial lists of supported currencies
are displayed on the form view and are editable, because Odoo lists may
not be up-to-date. Empty lists do not trigger any filtering on the
payment providers to access payment methods.
For Authorize.net and Asiapay payment providers, the specific
`(authorize,asiapay)_currency_id` are removed and the generic payment
provider field `available_currency_ids` is restricted to a single-item
list when one of those providers is enabled.
task-2926016
closesodoo/odoo#101018
Related: odoo/enterprise#34158
Related: odoo/documentation#2788
Related: odoo/upgrade#4069
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
Changing the name of model payment.acquirer to payment.provider
and everything that it touches. It is technically incorrect to
use the term "acquirer" for systems that only provide a service
of payment.
After this commit the model payment.acquirer and all related to
it will be renamed to payment.provider.
Task - 2842088
closesodoo/odoo#90899
Related: odoo/upgrade#3542
Related: odoo/documentation#1981
Related: odoo/enterprise#27131
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
