I read https://medium.com/square-corner-blog/webhooks-in-the-square-connect-api-d4d38c4b4d9f, which implies that the webhook entity_id will be a payment_id. If I have a refund for a single tender order, the payment_id and the entity_id of the webhook match. However, when I refund that payment to multiple tenders, the id in the webhook is the tender id for the first tender and I only get one webhook. The payment_id that gets returned from the payments api is different.
Can someone please verify what entity_id is here? Is it always the tender_id of the first tender?
Be sure to read the webhook documentation as well. It will always be a payment_id that you can use the Retrieve Payment endpoint to get more information from.
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.
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.
After placing order customer gets email with information about this order what includes payment method. If customer doesn't pay the order on the page where did he place it, the order still exists in customers acoount as pending or processing (due to payment method).
Where or what should I look to make link for payment for unpaid orders?
Or should they just "reorder" it?
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 have made some changes to Magento order email templates and code so that customers in retail and wholesale customer groups receive differently formatted email confirmations. i.e. One group receives an email showing VAT/TAX the other does not.
This works fine except for orders paid with Paypal. With a paypal order my logic for detecting the group ID is failing. Can anyone shed any light as to why this might be happening? Is the response coming back from paypal somehow not associated with the customers group? If so can I perform a check after a successful paypal ipn response to ensure the system keeps the customer in the right group.
I am retrieving the customer group from the customer/session perhaps I should be getting it directly from the database?
Any assistance would be much appreciated!
Thanks to Anton for pointing me in the right direction. After a paypal payment group ID in the session is set to 0 - not logged in!
Makes much more sense when working on events and code after an order is placed to get customer info from the saved order, so in my case the following returned the correct Group ID for me to use in order confirmation email code etc.
$_order = $this->getOrder();
// get group id from order
$groupId = $_order->getCustomerGroupId();