- Stripe needs to have the amount in integer, so we have to multiply by 100 the amount.
Which sometimes create float representation errors and remove/add ~1 cent on some transactions (i.e 72.60€)
- When creating a Stripe charge, we have the possibility to send the customer email.
This is then used by Stripe to send a payment notification (receipt) to the customer.
This was never done by Odoo, this commit introduce this feature.
OPW-1829945
Before this commit, when accessing the payment page with arbitrary amount
(/website_payment/pay?reference=Testinvoice&amount=150.0¤cy_id=6&country_id=)
A traceback was thrown because the keys concerning the partner were not present in the dictionary
that prepares the values for the form that we send to Stripe
Considering that those info are not mandatory for stripe (although not very good practice -- the more info the better to verify an identity)
we ignore them if not present
After this commit, the public route works fine
OPW 1832164
closes#23948
`str.format()` is only safe with byte-strings arguments, not unicode.
Unicode parameters would be automatically encoded using 'ascii'
encoding, resulting in a UnicideEncoreError in case any non-ascii
characters are present, which is quite likely.
Using '%' formatting on a str format string works the other way around,
and will cause the format string to be decoded into unicode if any
unicode params are present. This is typically safer because we never
use non-ascii characters in our format strings.
It also feels more natural than having to coerce the format string to
unicode using a u'' prefix.
This issue does not occur in Python 3, where either syntax will work.
Depending on the payment flow, the `email` field may not always be
present in the token data coming from Stripe.
Currently, it is missing in s2s mode, because we do not send it.
To avoid a KeyError during creation of the customer, we can use
token["card"]["name"] instead, which is always provided (it contains
either email or cardholder name), or the explicit ` description`,
when provided.
- There was no feedback to the user when executing the Charge
transaction in server-to-server mode, while it could take several
seconds, with the normal UI/action buttons still available.
- Stripe integration was almost working along with `website_quote`
payment, but entirely broken with `website_payment`, and partially
broken with `website_sale`.
Fixing it required:
+ More leniency in processing optional transaction parameters, which
may or may not be present in the various payment flows.
+ It also required more precautions when locating the transaction for
which the Stripe Charge was to be created, which passed in different
manners in the session. The route now supports an explicit `tx_id`
to allow forcing the transaction without risk of mixing different
payment flows.
+ FIXME: There is still some amount of duplication and bad modularity
in the handling of the various payment flows in relation with
Stripe.
- We provided very little metadata to the Customer and Charge APIs of
Stripe. We now pass more names and references to make Stripe payments
easier to manage in the Stripe dashboard.
- In some cases, selecting Stripe as payment method caused a second
inclusion of `stripe.js`, raising a JS error because of the
duplication.
- Strip whitespace in emails: the Stripe API raises an error for
transactions done with invalid emails, including with
leading/trailing whitespace.
Customers will have a hard time figuring out the problem
by themselves, so we should at least strip whitespaces.
To reproduce:
- Buy a product costing 0.01
- Validate the cart, pay with Stripe
- Enter the credit card info, validate
Stripe cannot process the transaction (minimum charge is not met), but
the user is not warned about it. The Stripe pop-up is closed and the
error is recorded in the console silently.
opw-765775
- 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.
The callback_eval field has a groups parameter of
base.group_system. Without this patch everyone not part of that group
ends up with an access right error when the system attempts to read
that field.
Previously this was not a problem because all code reading
callback_eval was executed with the superuser already. New code has
been introduced however that does not do this (eg. paying with a
payment.token from the backend).
opw-741181
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.
The email of the recipient must be specified in the charge.
The checkout.js prompt creates a token with the email specified as the name but
to get an email confirmation that the charge succeeded, the receipt_email
parameter must be set.
Side note: the receipt_email is not enough to send email confirmation, it must
also be enabled on Stripe dashboard that generated the access tokens.
Reference: https://support.stripe.com/questions/email-receipts
opw-697759
The module `payment_stripe` was apparently not designed to work with
module `website_payment`, althought the payment method is available. For
example:
- Go to '/my/home', select "Pay Now" on an invoice
- Try to pay with Stripe ==> nothing happens
This commit brings the necessary modifications to make it compatible
with `website_payment`. Moreover, it prevents the creation of 2
`payment.transactions`, which was not necessary.
opw-693421
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.
show logo, merchant name, description, currency and amount on the stripe
checkout page.
Add the field stripe_image_url to display the logo that was configured according
to https://stripe.com/docs/checkout
Do not use company logo as there is no guarantee on the image ratio.
Closes#12378
-*- 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/'
Toufik Benjaa