d
Topic
Posts:
591
Last edited August 11, 2014
g
1
upvotes

[Deprecation][Orders API] order.gateway and order.payment_details This post is outdated

Due to the reality that an order having a single transaction for payment is no longer always true (point of sale, gift-cards, etc.) we are going to be deprecating the gateway and payment_details fields on Order.

All of this information can be found via the orders transactions which can be accessed by making an API request for that order. An example of such a request would be something along the lines of:

GET /admin/orders/:order_id/transactions.json

These changes will be coming in effect on November 1, 2014

i
Replies
Posts:
2
August 11, 2014
g
1
upvotes

Can you say when single transactions for payments will be deprecated?

Posts:
591
August 11, 2014

I've updated the post. These changes go out on the 1st of November.

If a shop is not using any of the new features (Point of Sale, Gift Cards) then it's basically still a single transaction, which will never go away. It's just the way you access the transaction information that is changing.

Posts:
13
August 11, 2014
g
2
upvotes

Would it be possible to update the orders API to return a collection of transaction objects on the order? It would be great to get all this in one API call rather than having to call once for the order and again for the transactions.  I'm thinking it would work just like the line_item and fulfillments lists that are already part of the order data returned.

 

 

Posts:
591
August 12, 2014

There are some performance implications we need to address before we can do that. This was the original plan but there's some other things that need to be addressed before this can be done.

Posts:
2
August 12, 2014

Any chance those things can be addressed by November 1st? :)

-- Matthew Watkins Developer
Posts:
218
Last edited August 14, 2014

+ 1 for getting the transactions in the order object before November 1st :)

This is critical for one of our applications, which sucks in up to 250 orders at a time and then creates Invoices out of them in realtime.. each of these needs the transaction info. So we'd be going from 1 API call to 251 API calls while the user waits.. which will of course be impossible with the new API limit (and not to mention much much slower).

Or, you could very kindly keep the "old" fields on there until you get it worked out?

Thanks, and god speed!

Bjorn Forsberg | FORSBERG+two | Award-winning Shopify Apps since 2011
Posts:
218
September 02, 2014

Any chance this will be solved by November 1st? It's actually critical for 2 of our apps, which process and import Orders in bulk.

Bjorn Forsberg | FORSBERG+two | Award-winning Shopify Apps since 2011
Posts:
591
September 02, 2014

If any of your merchants use gift cards that payment information on the order is going to be invalid because you'll be missing information. I'm trying to work on something to bring in Transactions into the order but there's some things getting in the way.

Posts:
218
September 03, 2014

Thanks Chris, understand about the Gift Cards but that would be much more manageable than no Transaction on the Order ;)

Bjorn Forsberg | FORSBERG+two | Award-winning Shopify Apps since 2011
Posts:
2
Last edited October 02, 2014

For anyone looking to avoid making a ton of API calls to get transactions when getting orders in bulk, here's a solution:

Though it's not publicized, Shopify has several "experimental" features to get more out of the API. These can be invoked using the "_apiFeatures" querystring key with the value of a comma-separated list of experimental features to enable for that call. Chris's team's work to include transactions in the order payload itself is one of these features.

So, if you add the querystring "_apiFeatures=include-transactions" then you will get the transactions for that order as a field in the order itself.

This works for individual orders (ie. "/orders/{id}.json") as well as for querying for orders in batch (ie. "/orders.json?limit=250").

It's still experimental, so there's no guarantee it will always be there and be functional, but if you write your code to issue a call to the transactions API if that gets returned null as a fallback, you should be pretty safe. 

Another tip: Adding the "include-risk-analysis" feature will include orders risks in the order's payload, too (ie. "_apiFeatures=include-transactions,include-risk-analysis"). Use them together, and you only have to make at most one single call per order (instead of 2 or 3).

-- Matthew Watkins Developer
Posts:
1
October 07, 2014

Can you please make sure that the transaction list gets added to orders sent via the order webhooks.

Posts:
218
November 04, 2014

Matthew, just wanted to say a big thanks for the info above regarding the feature flag. That did the trick in ensuring we don't have to hammer the API to get the transaction info, and only do it when really necessary (like on webhooks received)   :) 

Thanks again!

Bjorn Forsberg | FORSBERG+two | Award-winning Shopify Apps since 2011
Posts:
3816
November 04, 2014
g
1
upvotes

I find it awkward at best that non-Shopify partners are providing information like this to the community at large. It implies back-channels and preferential treatment for some but not all. When my clients registering millions of dollars through the Shopify cash registers complain about treatment it is true the leaf does not fall far from the tree. 

 

Custom Shopify Apps built just for you! hunkybill@gmail.com http://www.resistorsoftware.com
Posts:
3816
November 06, 2014

Wow. This is a mess. Looking at the JSON of an order, it looks nothing like the reality in the documentation and you have not deprecated things like payment_details. 

Please try harder to help us out here. It is NO FUN as Iggy would say to work with such an imbalance between reality and fantasy in place.

Custom Shopify Apps built just for you! hunkybill@gmail.com http://www.resistorsoftware.com