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.
Related
When working on an application in microservices architecture I stumbled upon issues concerning coupling between services.
This a typical application for ordering products. It seams reasonable to have a service that will operate as a product catalog. Our JavaScript client can ask this service for available products and show them in browser. When user clicks on a product we have to create an order. We would like to manage orders in another service. So an order is created - it means that user X ordered product Y. On the technical level we are simply persisting user id and product id in a database.
To sum up we have:
Products service
Product class:
Product ID, Product Name
Orders service
Order class:
Order ID, Product ID, User ID, Order date
Now let's imagine following scenario - in JavaScript client we would like to list all products that user have ordered. Orders service provides a list of products ids for a given user. But user cares about product name, not the id. Unfortunately Orders service doesn't know anything about products names.
We could tackle this in couple of ways:
Simply assume that the client is responsible for getting the information it needs. So after it calls Orders service and gets a list of products ids, it performs another call to Products service, passing products ids and getting corresponding products names in response. Then the client assembles both responses into something useful. This approach keeps our services clean, without leaking of domain knowledge from one service to another. But it requires more work on the client side.
Orders service when asked for ordered products makes a call on the backend to the Products service. It retrieves product names, assembles a response that contains orderDate and productName and sends that to client. All that's left for client to do is to present the data. Downside of this approach is that Orders service now gains more knowledge about products than neccessary.
Duplicate information about product name in Orders service. When an order is created, we pass not only product id but also product name. That means that Order class will look like this:
Order class:
Order ID, Product ID, Product name, User ID, Order date
Now we can easly provide full information about order without additional call to Products service. Also this time Orders service has too much knowledge about products. What's beneficial tough is that Orders service can provide relevant data even if Products service is down.
Could any of these approaches be considered best practice? Or are there different solutions?
In the eShopOnContainers example( https://github.com/dotnet-architecture/eShopOnContainers ), they add the following fields at the time an order item is created:
public void AddOrderItem(int productId, string productName, decimal unitPrice, decimal discount, string pictureUrl, int units = 1)
This duplicates the catalog information, however as this is a point in time snapshot of the record. This is far safer than linking to the original data.
At this point in the user journey you are in the domain of an order, if a user is viewing an order you can provide a link to the catalogue. However, the order service should be able to operate independently. Linking back to the catalogue for the information on products prevents the Order service owning it's own data.
A nightmare scenario being that a price changes in the catalogue... What would happen to the historic orders?
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
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.
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.
I want to be able to send different order confirmation emails to new customers than to established customers.
I am already able to put a block in the email template to insert my own 'if' constructs based on order details.
I can get the customer data from the order id, e.g. the customer id, but how can I determine if they are a new customer?
Even if it is getting the customer creation date and checking if it is less than five minutes, I need a technique to determine if they are new from within my template code based on the order information.
Either way your going to just have to do calculations on created_at field in the customer_entity table. If not your going to have to find some specific window to consider customers as "new".
Don't think I'd put said logic in the template file but rather a model and just pass it a block to flag it or not.