I just found that when using the Square Register SDK on iOS, if the "Skip Receipt Screen" setting is turned on at the Square's Point-of-Sale app(ver. 4.62) side, there will be no transaction ID passed back to my app. Is it a bug of Square's Point-of-Sale app?
You need to use the client id and then use the REST APIs to pull down the recent transactions and find the one with the matching client id.
Related
I'm trying to get an Android Wear watchface set up that gets the number of steps the user has taken. To do that, apparently I have to get the data from Google Fit. Step 3 of that process is getting an OAuth 2.0 client id. I'm following the steps in the link below.
Request an OAuth 2.0 client ID in the Google API Console
The first step is clicking the blue GET A CLIENT ID button. In there I select my project and click Continue. That enables the Fitness API. Then I click on the blue Go to credentials button. There I choose Android for where I'm calling the API from and User data for the type of data that I will be requesting. Then I click the blue What credentials do I need? button.
This page is where the problem lies. I am supposed to enter a name, SHA-1 fingerprint and package name. However, all three fields are disabled so I can't type in them. If I go ahead and click on the blue Create OAuth client ID button, it marks those three fields in red with some verbiage about being required. I still cannot type in the fields.
How is this supposed to work?
I was facing the same issue today. In case you haven't found a solution to your problem, you can try creating a project with a different Google account. I think it happens because of the conflict with your previous projects.
I'm working on an app that uses the Square API to react to Point-of-sale events. For example, a customer goes to a take-out restaurant. The restaurant uses Square to accept payments. The customer pays cash. At that point, Square sends a notification to a custom webhook with the PAYMENT_UPDATED flag. Then, the app I'm working on should send a push (APNS) notification to the device that just accepted the cash payment.
The problem is that I haven't found a way to single out a particular device within a Square location. So what ends up happening is that all devices registered to a Square account get the push notification.
The user registration workflow is as follows:
A business launches the app and gives permission to receive push notifications (this is where we get and save the device token).
The business registers for an account.
The business authenticates with Square (allows our app to receive Square notifications).
I feel like there should be a way to associate a device token used for APNS with a device ID linked to a Square Location (and subsequently accessed via Square's Location API), but I haven't been able to figure it out.
Any thoughts or suggestions? Thanks!
UPDATE
The code isn't really the issue. By that I mean whether we're using PHP, Java, Ruby, etc, the issue remains the same. The only solution I can think of would be to use Square's SDKs to build a completely custom POS system, but that'd be like using a sludge hammer to put a tac in a wall.
The ultimate goal is to simply create a relationship between a Square device and a user's device I have stored as a record in my sql database. Seems like it should be straight forward, but not so much.
We recently launched the app which has only consumable in-app purchases. We noticed lot of fake purchases - purchases with invalid receipts and also 'valid' receipts but the "in_app" array in the validation response from apple is empty array. I need to know how users are forming such a 'valid' receipts ? Is it the receipt of the app download and not of in-app purchase or what ? I am now putting the following check for validation. Extract "in_app" field in json response from Apple and if it is non-empty, then check the product_id matches or not. I need to know if this check is enough or their is a better fool proof check.
All apps have a receipt. Those apps that have purchased an IAP have an in_app field in their receipt. Your users are pushing a fake call into their updatedTransaction method and you are grabbing their receipt (sans IAP cause they made no purchase)and sending it to your server. Other users might swap some receipt from somewhere (e.g. one of 30 thieves makes a purchase and extracts that valid receipt and sends it to their 29 co-thieves). If they stick that receipt into their device and then push a call to updatedTransactions then your server will get their now-valid-but-duplicate receipt. Your server needs to check *** the date of the receipt and discover it is older than recent or, even better, older than the paymentRequest which you would need to co-send to your server. (it is better to decode on the device - much more secure)
*** you used to be able to check transaction_id for a duplicate transaction_id. Unfortunately you can no longer do that since a restoreCompletedTransaction returns the same transaction_id as the original purchase. I have told Apple about that and they ignored me.
Refer to this In-App Purchase FAQ My app validates its receipt with the App Store via paymentQueue:updatedTransactions: after a successful purchase. However, the returned receipt contains an empty in_app array rather than the expected products.
An empty in_app array indicates that the App Store has not recorded
any transactions for the user yet. It may be that the application
receipt has not yet been updated. When this happens, your app can
inform the user that the receipt does not appear current and ask
whether to refresh it.
Information about consumable products is added to the receipt when
they are paid for and remains in the receipt until you finish the
transaction. After you finish the transaction, this information is
removed the next time the receipt is updated. Thus resulting into an
empty in_app array if your app only sells consumable products.
I'm porting a working application from previous iOS's and am having trouble with the new in app purchase receipts.
The way we work now is to take the transactionReceipt property from the SKPaymentTransaction object and send it to the server for validation.
From what I could gather from other questions, it seems that the receipt is now held in one place, being :
[[NSBundle mainBundle] appStoreReceiptURL];
There are a few things I don't understand here :
Is there now one receipt for all of the purchased products?
If so, does this file grow and grow and grow?
If I want to send single receipts for single products to the server, how can I?
Is the only way to send the full file to the server all the time?
Very confused by this, any help would be greatly appreciated.
From what I've been able to gather via Apple's documentation.
1) There is one receipt for all purchased products. In order to perform server side validation you send the entire receipt to your server, which forwards it to Apple for verification. See this post on the Apple Developer Forums (starting around comment 13) https://devforums.apple.com/thread/193893?tstart=0
2) Non-consumables will remain in the receipt forever, so yes it will grow and grow. Consumables are removed lazily from the receipt once finished via a call to finishTransaction. See https://devforums.apple.com/message/876265#876265
3) The iOS6 way of looping through updatedTransactions and sending individual receipts to your server for validation seems at odds with the new iOS7 design. This post on the Apple Developer forums suggests you "Send the whole list of transactions to your server with the receipt. When the receipt is verified, deliver all of the products, and finish all of the transactions." https://devforums.apple.com/message/897870#897870
4) That really does seem to be the case.
If you believe the iOS7 documentation is lacking you can raise a bug report with Apple
With the release of the new subscription option from In-App Billing API we started a proof of concept of the service and we found a few issues. Has anyone else tried it and would have some answers for us? Here's the issues we have been facing so far:
1 – While testing the unsubscribe functionality, the Google Play interface displays a white page with an “Item not found” message and a retry button. Is it due to the fact the app is not yet published? If yes, how can we test this flow without publishing it first?
2 – Inter device synchronization. When making a subscription on one device, other devices tied to the same account did not receive a OnPurchaseStateChange event. Is it again due to the fact the app is not published? Or are subscriptions tied to a particular device and not to an account?
3 – On our Google merchant page, when we cancel a purchase, the device does not receive a notification telling the subscription has been cancelled. Is this a bug? As a workaround we are manually checking the current time and comparing with the expiration date to force a restore transactions call. At this point, we are able to see the subscription is no longer valid. Do you think this is an acceptable solution?
4 – When a subscription is made, two transactions show up on the Google Merchant page: a FAILED transaction with a value of $0 and a valid one with the value we charged. Is this the expected behavior? What’s the purpose of the $0 FAILED transaction?
If anyone has faced similar issues we would like to know. Maybe these could be bugs on Google's end or maybe we did not understand 100% how it is supposed to work.
Thanks in advance.
1.I had the same issue and after I published (and later unpublished) my app I could see the app page in the market,so you can publish and than unpublish.
2.I didn't check it with subscriptions ,but for managed item i didn't get purchaseStateChange on two different devices as expected.
3.I do get subscription expired after canceling one,but only after a while.
I didn't understood how you can get the expiration date ?
you only can get it with access to play developer api.
the restore transactions will give you same purchaseStateChange as you got when purchase the item.
*in the developer guide it is recommanded to use restore transactions only in first app use.
4.I have same issue,and i heard at least about 10 people with same 0$ charge.