- When registering a payment token, validating it using a payment of a small amount (~1.50€) followed by a refund allows ensuring
that the payment method is valid (i.e. checksumming the card number simple ensure the number is valid but not that the card exists).
This commit introduces a generic approach that must be implemented for each acquirer that has tokenization support.
This commit also introduces a generic payment token registration/usage template that can be adapted according to one's need.
- Introducing a new payment form that handles payment, deletion and adding payment method (only for server2server for the moment).
- On /my/payment_method, changed strings 'Payment Acquirers' to 'Payment Methods' which is more clear.
- Stripe can now be used to pay subscriptions.
As this field is defined directly in payment and is displayed on
acquirer form view let us display it in tree view also directly
in payment instead of website payment.
When registering a payment token, validating it using a payment of a small amount followed by a refund
allows ensuring that the method is valid (i.e. checksumming the card number simple ensure the number
is valid but not that the card exists). This commit introduces a generic approach that must be implemented
for each acquirer that has tokenization support. This commit also introduces a generic payment token registration/usage template that can be adapted according to one's need.
payment_ogone: add support for tokens validation
Indeed payment module already adds a website_published button to ease
acquirer management directly in payment without link to website. The
mixin added in website_payment adds a website_url field that has no use
for payment acquirers and is not used at all in the current codebase.
As there is no website url the website publish button method is not
different than the one already implemented in payment. There is
therefore no need for this override, lessening model code in
website payment.
* add provider, related on acquirer_id.provider, in order to display
certain piece of information on tx depending on their provider;
* better tx form view and partner address display;
* remove unnecessary notebook on tx form view as it is not used;
* rename Payment Acquirers menu into Payment Methods, easier to
understand;
* acquirer kanban view improved to install / activate / configure them
depending on their state;
* be able to publish / unpublish acquirers without having to wait for
website_payment to add a button;
In 8.0 private fields have been recently set as visible only to employees
at commit b226510840.
However between v9 and v10 two new payment acquirers have been implemented
payumoney and stripe. Those addons now have their credential set as private.
Methods using the acquirers have been sudoed accordingly to avoid access
issues when rendering the buttons. Other payment modules will be updated when
the forward port from 8 to 9 and pre-10-master will be done.
Xpath has been altered and logos displayed in right column or portal.
The pupose of these logos is to know when you arrive on the website (ecommerce)
with which payment method you can paid.
Since saas-3, website controllers use `request.website.render`
to render the template of a web page. This was kept for retro
compatibility. It's time to stop using deprecated stuff.
Same for `_render` method on website.
'json' route don't use `request.render` since
`JsonRequest` has no `render` method.
I assume this was necessary before the migration of payment because
an api.one wrapper was added by the auto-guess api feature.
Since payment has been migrated, this decorator is no longer present
and the result of _registration_render is no longer encapsulated in
a list. Therefore, taking the zeroth element was akin to taking only
the first character of the rendered html. Usually \n, which is not
useful but which also prevented the crash to be easily visible.
tbe-odoo