In the example response for the List Payments endpoint in the Square Connect API Documentation, it shows 'Description' as a returned key, but the data I am receiving from Square does not show that key.
I have verified that the payments do have a Description attached to them (by downloading the transaction report from the Square Dashboard).
Thanks for identifying this inconsistency between the documentation and the API. The Payment object does not in fact have a description field.
However, the following fields included in a Payment object do contain merchant-specified notes about a payment (assuming the merchant provided them at the time of sale):
The payment_note field of a Payment’s tender contains a merchant-specified note about the form of tender used for the payment. This is generally present only for Tender objects with a type of OTHER.
The notes field of a PaymentItemization in a Payment contains a merchant-specified note about that particular item in the payment. Note that PaymentItemizations are only available from the Retrieve Payment endpoint (not List Payments).
The Description column of the transaction report provided by the merchant dashboard is simply a comma-separated list of the names of the items included in the payment, along with any notes for each item. The Connect API does not provide this list directly, but you can recreate it for a payment with the fields of the payment’s itemizations.
Related
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 am working in iOS / Objective C. I am building a JSON string and just using that to open square-commerce-v1://payment/create?data=JSON which opens the app. I can process payment and sent back to my app.
But I have a disconnect. How does my app know what transaction goes with whatever item?
For example: I rent cars. I have several cars in my inventory. I select "Car 4" and bring up the payment screen. Let the use pay and go back.
How can I send an id to square and then back to the app saying, that the payment was for "Car 4"?
You should look into notes if you want the itemization to be visible in your Square Dashboard. From Squares API documentation:
This note is included in the itemizations field of Payment objects
returned by the List Payments and Retrieve Payment endpoints.
If you are looking to do item and inventory management, or pull prices from an item, you'll need to use the Square Item APIs.
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
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.