This repository has been archived by the owner on Aug 7, 2024. It is now read-only.
[GRO-11382] Add Stripe 16+ support #18
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Log of the CI before this commit: ``` $ if [[ $TRAVIS_PYTHON_VERSION != nightly ]]; then flake8 .; fi ./localstripe/resources.py:594:47: E741 ambiguous variable name 'l' The command "if [[ $TRAVIS_PYTHON_VERSION != nightly ]]; then flake8 .; fi" exited with 1. ```
Made from Stripe documentation: https://stripe.com/docs/api/charges/list#list_charges-customer
Since commit 4810d4b _coupon: use float value for percent_off_ the following unit test is failing: ``` ... + curl -sSf -u sk_test_12345: http://localhost:8420/v1/coupons -d id=PARRAIN -d percent_off=30 -d duration=once curl: (22) The requested URL returned error: 400 Bad Request ``` It's because, in the code just after 4810d4b change, the expected type for `percent_off` is still `int`.
In Stripe [documentation of the Charges list API], all parameters are optional. Since commit 54831f9 _Charge: Add `customer` and `created` to the list API_, localstripe support parameters `customer` and `created` but both were made mandatory. Let's fix them. [documentation of the Charges list API]: https://stripe.com/docs/api/charges/list
Let's add the property `billing_reason` that was missing. For the moment, it's not implemented so it's always `null`. https://stripe.com/docs/api/invoices/object#invoice_object-billing_reason
Problem: very recently, Travis started to fail on commit that were
previously fine. Probably a change on their side?
It appears that on some Python version (e.g. 3.7 but not 3.8) they
double-escape `%5B` and `%5D` caracters, so they are passed as `%255B`
and `%255D`.
To avoid that, I propose to use `[` and `]` directly, and enable curl's
`-g` option (`--globoff`) so that it doesn't interpret them.
In summary now the commands are a bit clearer:
curl -sSfg -u $SK: $HOST/v1/plans?expand[]=data.product
And drop support on Python 3.5 and 3.6.
The current implementation supports the Balance resource as described in https://stripe.com/docs/api/balance
`None` is already the implicit default when using `get()` on a dict.
react-stripe-js checks for createPaymentMethod to validate the stripe object. This fixes adrienverge#147.
createToken contained a reference to an undefined variable left over from an earlier, incomplete change.
Returning the created Element requires that `elements` keep a reference to it. In turn, we have to change the style a little bit from arrow functions to `function()` because arrow functions do not bind `this`.
`Element.mount()` incorrectly expected the result of `document.querySelector()` to be an array rather than a single DOM element.
The Stripe.js docs do not specify much of the interaction among [`mount`], [`unmount`], and [`destroy`] so most of the following description came by experimentation. `mount` adds the Stripe element to the given DOM element. `mount` has no effect if its argument refers to the same DOM element to which the Stripe element is already mounted. It throws an exception if the Stripe element is already mounted, unless the argument refers to the same DOM element on which the Stripe element is already mounted. It also throws an exception if the Stripe element has been destroyed. `unmount` removes the Stripe element from the DOM. It is idempotent. Stripe.js throws an exception if the Stripe element has been destroyed; our version does not. `destroy` destroys the Stripe element, removing it from the DOM if necessary. There can be no more than one Stripe element at a time with a given type, so you must call `destroy` before creating another. Stripe.js throws an exception if the Stripe element has been destroyed; our version does not. This all requires some extra bookkeeping in `Element`, so it has two new "private" fields that are not present in a real Stripe object: 1. `_domChildren` tracks all of the DOM elements created by `mount`, and is used both to tell whether the Element is mounted and for `unmount` and `destroy` to remove the DOM elements. 2. `_stripeElements` keeps a reference to the `elements` object that created the `Element`, so it can make the `elements` allow another call to `create` after `destroy` is called. [`mount`]: https://stripe.com/docs/js/element/mount [`unmount`]: https://stripe.com/docs/js/element/other_methods/unmount [`destroy`]: https://stripe.com/docs/js/element/other_methods/destroy
Localstripe uses the `store` object to store data between localstripe executions.
But I just noticed that some TaxRate attributes are not saved properly.
It's the case for a few properties of the TaxRate object.
Reproduction:
- launch localstripe from scratch `python3 -m localstripe --from-scratch`
-
$ curl -sSfg -u sk_test_12345: http://localhost:8420/v1/tax_rates \
-d display_name=VAT -d description='TVA France taux normal' \
-d jurisdiction=FR -d percentage=20.0 -d inclusive=false
{
"active": true,
"created": 1616511744,
"description": "TVA France taux normal",
"display_name": "VAT",
"id": "txr_hG2CLNRGQMy35a",
"inclusive": false,
"jurisdiction": "FR",
"livemode": false,
"metadata": {},
"object": "tax_rate",
"percentage": 20.0
}
- Kill localstripe
- Relaunch localstripe `python3 -m localstripe`
-
$ curl localhost:8420/v1/tax_rates -u sk_test_12345:
{
"data": [
{
"created": 1616511409,
"id": "txr_GDaiJpS2uF5zIj",
"livemode": false,
"object": "tax_rate"
}
],
"has_more": false,
"object": "list",
"total_count": 1,
"url": "/v1/tax_rates"
}
It's probably the case for other objects too.
For me the easiest solution is to always dump the store to the disk just before
answering PUT POST and DELETE HTTP requests.
This commit makes the assumption that invoices in localstripe are either fully paid (amount_paid == amount_due) or not paid at all (amount_paid = 0). This behavior can be different with real Stripe servers. Tested with my end-to-end tests without any error.
Using `setup.py` is deprecated and the new recommanded way is to declare a `pyproject.toml` file (see PEP 517 [^1]). This commit proposes to use setuptools to achieve that, because setuptools is already used by localstripe, is standard and referenced by the official Python packaging documentation [^2], and seems to be the most lightweight solution. For some period, the `setup.py` file will be kept (although almost empty), to allow old tools versions to keep working. I have done the same migration for yamllint 7 months ago [^3] and it appeared to work well. [^1]: https://peps.python.org/pep-0517/ [^2]: https://packaging.python.org/en/latest/tutorials/installing-packages/ [^3]: adrienverge/yamllint#566
calm-mlin
force-pushed
the
ml/calm-stripe-next
branch
4 times, most recently
from
ed5bc10
to
3204eb9
Compare
calm-mlin
force-pushed
the
ml/calm-stripe-next
branch
from
3204eb9
to
4811d5c
Compare
calm-mlin
force-pushed
the
ml/calm-stripe-next
branch
15 times, most recently
from
ca251cc
to
e4ff1c9
Compare
calm-mlin
force-pushed
the
ml/calm-stripe-next
branch
from
e4ff1c9
to
0c220db
Compare
calm-mlin
force-pushed
the
ml/calm-stripe-next
branch
from
0c220db
to
fb01529
Compare
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR updates localstripe to it's latest version. This means that only Stripe 16 will be supported.
I made some extra updates to simplify the sync in the future (as we are working toward staying up-to-date with Stripe):
LS_HOSTwithHOSTwhile keeping in mind the original reasoning behind it (it's still reading the content ofLS_HOST)Note: