It was very confusing for the user to distinct account.payment and payment.transaction. From now on, the transactions are
technical objects and, in the backend, we only refer to it in log messages (Front end will be adapted in the same fashion
later on). They are hidden in debug mode in accounting\configuration\payments as their purpose is now purely technical/log
This commit also aims to reduce the gap between the accounting app and the transactions: account.payment objects are
created/validated upon completion of transaction.
To ease the capture/voiding of pending transactions, the related buttons are now displayed directly on the SO/invoice
instead of the transactions.
Was task: https://www.odoo.com/web#id=35857&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #24043
[FIX] add domain based on journal to payment tokens
Was opw: https://www.odoo.com/web?debug#id=1828206&view_type=form&model=project.task&menu_id=5200
Complements rev. 9b1009cd5a to fix the
handling of validation transactions for 3DS-enabled cards.
This handles a few issues:
- make sure to trigger the refund for validation transactions even if
the first feedback we get is the S2S feedback
- feedback URL called by the users' browser should not reset the payment
transaction to 'done' when the refund process has been initiated
- status 81 for "refund pending" should not end up with a transaction in
error. It may be that Ingenico will send a feedback transaction later
or not at all, but the refund is likely to succeed at that point.
Without this commit, validation transactions would never be refunded for
3DS cards.
Remaining issue: the return_url does not seem to be set for those
validation transactions, so the user ends up on the homepage after
completing the 3DS step.
The validation transactions introduced in
7d428c871b were not working properly for
Ogone, due to several problems:
- The refund requests when being sent via the orderdirect.asp API, which
does not support refunding previous transactions, according to the
Ingenico helpdesk. It only support creating independent refund
transactions, which is something that requires special pre-approval
from the payment acquirer, and generally not permitted.
In order to cancel/refund a previous transaction, the direct
maintenance API must be used instead[1].
- Maintenance requests to refund a previous transaction fully should use
the RFS code, as explained in the API documentation [1], and should
always mention the PAYID of the refunded transaction.
- Such maintenance requests must always be SHA-signed, as usual.
- The various transaction status codes for refunded transactions need to
be taken into account as well (typically those beginning with 8)
This commit fixes these various problems.
[1]
https://payment-services.ingenico.com/int/en/ogone/support/guides/integration%20guides/directlink
(5.2 Direct Maintenance)
As of today, Ingenico platform 4.125 has non-uniform handling of the
PARAMPLUS parameters that can be passed as part of transaction metadata.
This parameter is documented as being parsed[1] as a series of
parameter-value pairs, to be passed as extra parameters to the feedback
transaction. Based on this, it seems that the PARAMPLUS value should not
be urlencoded globally, but each field value should be urlencoded, as
the Ingenico side will have to be able to parse and re-emit these
individual parameters.
In one case we were missing this urlencoding step, so this commit fixes
it.
Without this, the querydirect.asp API would return invalid XML data when
we retrieve the status of a transaction that used a PARAMPLUS value with
an '=' sign!
For example with PARAMPLUS passed as
return_url=/payment/confirm?tx_id=123
the value returned by querydirect.asp would contain the following:
(note the invalid extra quote character in the `return_url` param)
```
<?xml version="1.0"?>
<ncresponse
(...)
ED="1234"
return_url="/payment/confirm?tx_id="123"
SCORING=""
SCO_CATEGORY="G">
</ncresponse>
```
Url-encoding the value of the return_url in PARAMPLUS fixes this
nonsensical result.
However, the Ingenico API then fails to decode the parameter value when
passing it to the feedback URL, such as the ACCEPTURL we depend on.
As a workaround, since we only pass a single parameter inside
PARAMPLUS, we'll url-unquote it afterwards.
[1]
https://payment-services.ingenico.com/int/en/ogone/support/guides/integration%20guides/e-commerce#feedbackparameters_variablefeedbackparameters
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
* StringIO removed from stdlib, replace with io
* try to correctly handle BytesIO/StringIO (one is for bytes the other
is for text)
* fix base64: Python 3 removed bytes-encoding and bytes-bytes
codecs (via #encode) so replace all calls to str.encode('base64'),
also b64encode is a bytes->bytes conversion so attempt to properly
handle that
issue #8530
- 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.
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
In Python 3, all of these were "consolidated" under urllib(.request,
.parse, .errors) which is inconvenient.
Since we already have hard dependencies on requests and
werkzeug(.urls, which is a backport of Python 3's unicode-aware
urllib.parse) migrate *everything* to that.
A sticking point is urllib2.URLError, those were (mostly) replaced by
the slightly more general IOError which URLError extends.
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
callback_eval is currently a code string that is evaluated directly
at payment confirmation. This commit changes it to have parameters
on the record and method to call on it. Moreover a hash done once at
transaction creation ensure that a modified transaction does not allow
to execute code on other records.
This commit improves the tokenization process, allowing users
to set the acquirer to save payment data never, always or letting
the customer decide (only implemented in ecommerce for now).
Support for tokenization is improved for Ogone and Authorize.net
This commits also factorizes advanced payment features support
(authorization, tokenization, fees computation) in a generic method
overriden by every provider to specifiy which features are supported.
This process can be used in views to hide/show fields depending on
feature support or in constraint checks.
-*- coding: utf-'8' "-*-"
is not a valid encoding. Introduced by
666387a274 I think. It was probably a
typo/replace gone bad and it got copy-pasted everywhere. Emacs complains
every time you try to save changes to files with this invalid encoding.
This changes all of them to
coding: utf-8
adhering to eae045949d.
Done with:
find . -name '*.py' -print0 |\
xargs -0 sed -ie 's/-\*- coding: utf-'"'"'8'"'"' "-\*-"/coding: utf-8/'
The Automated File Upload (AFU) Ogone API requires a transaction code to be set,
either:
- ATR for automated transactions
- MTR for maintenance operations
The default is ATR and is used for submitting transactions in batch.
However, the server-to-server mode of payment_ogone only uses the AFU
API to create new credit card aliases, and not to process transactions.
Using the ATR transaction code requires the ATR feature to be available
in the Ogone Merchant account - a paying option that is otherwise
unused. Using MTR as the transaction code is sufficient for adding
aliases, and the corresponding feature (MTR) is available at no cost
in most Ogone Merchant Accounts.
References:
- Ogone Advanced Batch:
https://payment-services.ingenico.com/int/en/ogone/support/guides/integration%20guides/batch
- Ogone Alias Management:
https://payment-services.ingenico.com/int/en/ogone/support/guides/integration%20guides/alias/bulk-alias-management-via-batch
Ogone responses comes from direct s2s calls or form feedback;
not necessarily in that order. The behaviour of the system should
be the same in both cases. This commit add payment_methode creation
when a s2s response contains the necessary information, juste like
the form feedback methods.
Ideally these methods should be merged to share the same code,
this will be done in master (v10).
Christophe Simonis