Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add idempotency to Stripe Update Calls #1910

Open
wants to merge 26 commits into
base: master
Choose a base branch
from

Conversation

arnav13081994
Copy link
Collaborator

PR #1909 needs to be merged before merging this as this PR builds on top of it.

This PR adds support for the user to:

  1. Pass in their own idempotency keys to Stripe Update calls.
  2. If the user does not pass their own idempotency keys, djstripe generates and uses its own.

@jleclanche
Copy link
Member

How is this PR split from #1909? I don't understand

This was done because Stripe does not expose a separate url to access these objects and they can only be accessed with the Related Source Object
This was done because the "Source" event handler was receiving all events of the type source.X.Y which was causing a mismatch between the event type and the target object type. This is why the target object type was explicitly checked as done for the "Charge" event handler.
This was done because newly created Sourcetransaction objects cannot be retrieved as Stripe doesn't allow `retrieve` operation yet. And in order to retrieve by the related "Source" object we need the source to be attached to a "Customer" instance which will not always be the case and can't be known ahead of time as the order of webhooks is unreliable. This is why retrieving the data of the SourceTransaction object was skipped.
The _api_update() method now does the following:

1) Generates a new Idempotency Key object if not given one using the
   Stripe object's ID that is being updated.
2) Uses the Idempotency key (from 1)) to make the Stripe API call.
@arnav13081994
Copy link
Collaborator Author

@jleclanche This PR builds on top of PR #1909 so only after that it is merged this would make sense. The first commit is PR #1909 squashed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants