#Durrell
dry roost
junior iron
If you're using the legacy cards api, we do have a delete card endpoint: https://stripe.com/docs/api/cards/delete
But with our newer payment methods api, those can't be deleted
vast lodge
we are using the most current API. Are you aware of any best practices for this edge case?
junior iron
With payment methods you have detach: https://stripe.com/docs/api/payment_methods/detach
Which disassociates it from the customer basically
That's the best way to do that
Are there concerns with any other Stripe objects?
vast lodge
We are using Connect and Issuing, so when these cards are swiped they will just be moving money out the Issuing Balance. We might upgrade to Treasury, in which case the money would be going out of the Treasury financial account instead of the Issuing balance.
So our current flow does not utilize the Customer object nor the PaymentMethod object.
The objects we are concerned about are the Stripe::Cardholder and the Stripe::Card objects.
tight plaza
Hi 👋
I'm stepping in as @junior iron needs to go
So when you say you want a way to roll back certain API requests. What is the action you are looking for?
vast lodge
It would be nice to delete the Stripe::Cardholder or the Stripe::Card if our local copies of those objects do not save for whatever reason right after we make the API calls to create the Stripe::Card and Stripe::Cardholder.
tight plaza
Unfortunately those are not API methods we expose. When you say you want to delete them when the objects do not save locally, what is the overall goal?
vast lodge
We are concerned with potential problems that might arise. For example, our user submits a form to create a card, then the API calls to Stripe succeed but our database fails to save copies of the Stripe::Card and Stripe::Cardholder for whatever reason so we show the user an error message, so the user submits the form again and then we make another set of API calls to Stripe to create a Stripe::Card and a Stripe::Cardholder again. The second time our database does save copies of the Stripe::Card and Stirpe::Cardholder, so our system knows about the second card and cardholder but not the first. What kind of problems might arise if there is a Stripe::Card and Stripe::Cardholder in Stripe's system but not in ours? If it's a physical card might you ship that card out? If you did, then our system would not recognize that card for authorizations.
There would also be fees associated with creating the first physical card that our system failed to save a copy of. I'm sure I could think of other problems.
If the API calls succeed we should have all the data we need to successfully save the copies to our database. We are just thinking of an edge case where our database server crashes or something and we cannot save anything.
tight plaza
Hmmm...
I think you would need to look more into what is going wrong with your local system than try to delete records in Stripe. The API is synchronous and will return the object created if it was successful. In my test integration I have been fairly successful in building and async task queue that handles keeping my local DB in sync with Stripe. That way when I make the API request and get a successful response, I immediately send that response to the user (e.g. "Success! You're a Card Holder!"). My integration hands the CardHolder object off to a task queue that takes care of writing it to my DB.
In the case where the DB crashes for whatever reason, if you have records of the customer and request time locally you can retrieve the objects from your account logs.
I also recommend using Webhook events as a way to keep. your local DB up to date. That way, if they fail to deliver because your system crashed, they will be retried.
Listening to events like issuing.card.created or issuing.cardholder.created will return the whole object as part of the payload.
https://stripe.com/docs/api/events/types#event_types-issuing_card.created
vast lodge
excellent. Thank you!