If a merchant issues a refund, does it show up in both the Refunds List and Retrieve Payment endpoint? Are there situations in which it may show up in one, but not the other (such as Cash, Check, or other Tender Types)?
The use case is an external app storing / caching payments where refunds need to update the stored payments to keep accurate sales figures. If refunds show up in both places, then it seems the best way to update stored payments in this use case is to load the Refunds List periodically and update the stored payment using the Retrieve Payment endpoint.
Regardless of tender type, every refund is available both from the List Refunds endpoint and from the List/Retrieve Payment endpoints. Your solution sounds like a good one, since the List Refunds endpoint is chronological by date of refund, as opposed to date of original payment.
You can use the payment_id included in the returned Refund objects to look up your stored copy of the corresponding payment.
Related
I am working on a SAAS project where users can create various projects. With each project, they can choose from 5 different plans. Each plan has its own costs per month. Hotjar is a kind of equal concept.
Now I want to arrange the subscription with Stripe. The problem with that was that a user can have a maximum x subscription, which of course was a shame. Then I decided to take 1 subscription that has several plans. But now I have a dilemma, to update the subscription you have to change the number via SubscriptionItem. Then you have to save yourself which plan has which SubscriptionItem_id for which user. That is quite a detour and can cause many problems.
Someone is a better way with Stripe or another payment software.
You don't necessarily need to store the subscritpion_item IDs, you can look it up via the subscription_item list API. All you need to do is store the subscription_id for your customers, and based on that ID you can retrieve the list of subscription_items:
\Stripe\Stripe::setApiKey("sk_test_9GavlLpfiKewqeCBXvRvmVgd");
\Stripe\SubscriptionItem::all(["subscription" => "sub_EQlPGjVj4o5luH"]);
Then you can handle the data part of the returned JSON object and update / delete / etc these subscription items.
If you only have the customer_id handy, then you can use the subscription list API (with status as well on the GET params) to retrieve the list of active subscriptions.
I am retrieving transactions via the Connect API v2, however, none of the returned records include order_id, customer_id, or cardholder_name.
All of this data is linked and viewable within the dashboard.
Am I missing something?
order_id - This field would only be filled if you used the CreateOrder endpoint and passed that order to the Charge endpoint for an itemized e-commerce transaction. It would not be there if you created an order in the Point of Sale.
customer_id - This is only filled in if the merchant (or app/site) explicitly attached a customer to the transaction. Some transactions get associated to automatically created customers that you don't have the data for, if you don't explicitly create the customer.
cardholder_name - You would only see this if the customer paid with Card on File. If you look at the data model in the documentation The cardholder name. This value is present only if this object represents a customer's card on file.
I'm trying to create a recurring payment on Square, ala Stripe subscriptions. However, I am having trouble retrieving a customer's card information (specifically customer_card_id) to pass into Charge.
Our flow is such:
A customer visits to our store and subscribes to a membership, which we process via the point of sale app.
We continuously poll Square to retrieve payment information, and create membership records appropriately.
When the user's membership period expires, charge them for the next month's membership.
When researching RetrieveCustomer, I find that there is a cards property under Customer, but iterating through all the Customers under our account, they all have cards = None despite us having taken card payments via the point of sale app.
Also, looking at ListTransactions, there doesn't seem to be anything that might be customer_card_id. The IDs I see there are tender ID, location ID, and transaction ID. The card_fingerprint also looks promising but that doesn't seem right either, since a card can have both an ID and a fingerprint.
Am I missing something? Where might I find customer_card_id?
EDIT
Looks like I was dumb and my local instance of our application was just out of date with transactions from Square. After updating my data with customers we've processed since the last time I updated, customers with a non-None card property now show up. tristansokol's answer below is still valid however.
How do you process the first charge? You need to explicitly add the card on file, it won't be added by default from processing a transaction from a customer. See: https://squareup.com/help/us/en/article/5770-use-card-on-file-with-the-square-point-of-sale-app
Basically what I want to do is show a list of stored payment methods of the customer so they can pick an existing one instead of putting in credit card info.
I know I can store customerId and payment token in my server. But I need a way to present and map the token to some basic card info (such as Visa, last for digits, Name), so the user would know which is which. And upon user submitting the form, I need to know which token they've selected.
What's the best way of achieving this?
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
With a customer_id, you can call Braintree::Customer.find("customer_id") to get a Customer object, and then call customer.payment_methods to get the list of payment methods associated with that specific customer.
The list of attributes of each PaymentMethod object will differ depending on whether it is a credit card, PayPal account, or Apple or Android Pay Card. For example, you can find the attributes for a credit card payment method on this page.
Each PaymentMethod object will also have a token, so when the user selects one of the payment methods, you can use that token to create the transaction.
I have an app that uses Parse as its backend, and has Stripe integration. On Parse, I store a Stripe customer id on my User class, and I have a custom class that has a charge token associated with it, so that a customer can create a service request, and when a provider accepts and fulfills that request, they can have the charge be sent to their recipient id.
A user could cancel the service request, or a provider could show up to the user's property and find that the property is unserviceable for various reasons. In this event, we have a cancellation fee that the users are charged.
I want to make sure that if the cancellation fee is charged, it gets charged to the same card that the user used to request the service. I noticed that when I fetch all of the cards from a customer id, they always show up in the same order, but when I add a card, it doesn't always add it to the end of the array that gets returned when I fetch cards. So, if I just stored the index of the card, a user could add a new card, and it would possibly take the place of the one that was being charged for the service. If I charged a card based on the index for a cancellation, it could charge the incorrect card. Would it be PCI compliant to store the cardID used to create the charge token on the Parse object that contains information about the service, so when I call my functions to create cancellation charges, I'm charging the same card?
Thanks for anyone who can provide some information on this.
The only sensitive data that you want to avoid handling is your customers' credit card number and CVC; other than that, you're welcome to store any other information on your local machines.
As a good rule, you can store anything returned by our API. In particular, you would not have any issues storing the last four digits of your customer's card number or the expiration date for easy reference.
from: https://support.stripe.com/questions/what-information-can-i-safely-store-about-my-users-payment-information