I am struggling to get our iPhone client into the App Store, and have been told that we have to add in-app purchases. But I have a couple of questions.
So far everything looks OK in the sandbox, except that I sometimes get an alert that looks like this:
Share your Information?
The publisher of Philip Sheard would like your name, email and postcode for use in accordance with their privacy policy.
[Environment: Sandbox]
Don't Allow | Allow
Now it should not be my name of course, or even the name of my company, but the name of the application. And we only really need the email address, not the name or the postcode. Is there any way I can fix this?
Also we would hope to receive an email message from iTunes whenever a purchase is made, which would hopefully include at least the email address of the purchaser. I am not getting this at the moment, but is that because I am testing it in the sandbox environment? Sorry for asking such a trivial question, but no one in our company has any experience with Apple culture.
the name is likely coming from your contract somewhere. but as for the email for each time a purchase is made is pointless, your app is handling the in-app buy, if its successful your own app could send an email or track the sale live however you wish. note in general its better to control such things on your end anyways.
Related
Tried searching for this in Amazon's docs but couldn't come up with anything.
Assuming that both email and phone number are checked in the verification section of the user pool. If the client app wants to allow the user to choose how they receive the code (assuming they've forgotten their password) - how do we get Cognito to handle that? Is there a way of getting the forgotPassword method to select a route (email or SMS)?
From some early testing, it seems like it always goes one route if both are available. I do see that Amazon themselves have made this available on their site though, so hoping that it should be possible?
For this example, we can assume that we've got a verified email address and phone number for that user.
I am on the Cognito team. Currently the behavior is that if both phone number and email are verified, the code goes to the phone, hence phone number is given preference and there is no way to select where the code actually goes. However, we have heard this request in the past and I will add a +1 to the feature request on your behalf.
I have a requirement to do 3rd party age verification before I ship an order. I'm using a company called EVS for this. They released a shopify app recently, but seems partly baked. It requires a user to enter date of birth when registering for an account and then triggers the verification when the user places an order. The main problem with that is that it's rare for a customer to actually create an account before ordering for the first time -- instead they order first, then shopify emails them to create an account after the fact. Creating the account afterward does not allow the customer to enter DOB.
So I'm planning to implement my own solution. I can use EVS's API to run the verification by sending a combination of Name, Address, DOB, DL# and State, and last 4 of SSN. I have already built a proprietary order management system that pulls in customer and order data, and I can write a client to perform the verification.
I'm less savvy on the shopify side. I need to balance customer friction when placing an order for the first time, against having to do a lot of manual work for verification.
Below are the options I have conceived. Are there any other options? Any ideas for a better solution? Keep in mind I need to verify a customer once. I can tag the customer account as verified, and once verified it's business as usual.
Alter shopify templates to only show the checkout button when a user is logged in. If not logged in, show a "Create an account" button instead. That way the user provides DOB during account creation and the EVS app works as designed.
Set up a separate verification site like verify.my-domain.com. I can trigger an email to the customer upon order creation and ask them to verify. (May have issues with incorrect email addresses or spam filtering.)
If customer is not logged in, or account is not age verified, and they click Checkout, I can redirect them to a page. I can use a form on the page to do the verification. If verification passes, send them on to checkout.
For option 3, I don't know what shopify allows or what best practices allow. Can I use js to pass data to my own server on a different subdomain? Or post the form to another subdomain and then redirect back to shopify?
I'd appreciate any thoughts or suggestions.
You have pretty much summed up all your options, to clarify on them a little:
You can require that customers create an account in the store checkout settings. /admin/settings/checkout
This would work, you could iframe it in too on a custom Page. Or, better, use cross-domain calls or jsonp.
This is a little convoluted and you would have to persist and maintain lot of external state. I'd avoid this
I think a combination of 1 and 2. Turn on "require customer account". Modify the customer account creation page. Implement a cross domain policy with your server which will host custom code leveraging the EVS API.
I'm not sure if you are selling tangible goods or not but with stringent policies on users' age you have to bear in mind that shipping addresses could change. For a tight integration you should look at having webhooks whenever a customer is changed and make sure all their data is still valid since their last EVS approval.
I've been looking into this quite extensively and we've spent a number of hours experimenting with options. Our client in this case is on Shopify Plus so we do have the benefit of access to checkout.liquid.
Our research has led us to believe that one cannot pass the required 'customer note' of the date of birth to the checkout should they be attempting to checkout as a 'guest'. Perhaps because the 'customer' does not yet exist.
Our options have been narrowed down to:
Write a custom backend app that allows Shopify and EVS to communicate directly (XML API on the EVS side) in the checkout process or just prior and then pass the verification status back to Shopify to allow the order to proceed, or append some relevant status marker for the fulfillment department to act accordingly. The EVS app doesn't prevent the order from proceeding, but does flag the customer's age as unverified in the Risk Level panel in the admin. This would be quite a substantial project and by no means low hanging fruit. There is also risk of re-doing a lot of what the EVS app does already and running into they same obstacles they did.
Force customers to register prior to checkout (if not signed in). This seems the most viable approach. The only caveat being that existing customers will not have the customer note (birth date) and we'd need to build a smaller backend app to allow them to append this to their customer account via the Shopify API (this cannot be done via liquid).
These are our findings and I'd love to know more about how you ended up approaching this.
I can not praise with my contribution here, because I am new user,
but would help if I can.
I have a big problem and I do not know how to solve it, please help.
In the same Paypal account with the default email address: email1#somedomain.com, there is 7 more emails:
email2#somedomain.com
email3#somedomain.com
email4#somedomain.com
email5#somedomain.com
email6#somedomain.com
email7#somedomain.com
that's the maximum allowed number of emails under one PayPal account (8).
So we are using API on several pages, and only one API signature can be done in the paypal
interface, so same API signature is used for each web page.
We would like to define where will money go - to which email address inside the same PayPal account.
We use Premium PayPal account, and we know that for logo change, email remove and so on, we would need Business account,
but for defining money receiver email address inside the same PayPal account
we suppose that it can be defined, otherwise we do not se a point of having several email addresses inside one same PayPal account.
The problem is that always is shown default email when making a purchase :S
We tried to define SUBJECT:
SUBJECT=merchantEmailAddress
N O T E: Typically, a merchant grants third-party permissions to a shopping cart...
And set merchantEmailAddress email2#somedomain.com.
In sandbox it works like a charm as soon as we put it on production, default mail is shown again.
Please if anyone had the same issue help.
Thank you very much, this forum is great and I realise that without nice people and contribution as well there would be no answers.
regards
You would not be using SUBJECT unless dealing with Permissions and making calls on behalf of 3rd party PayPal accounts.
You're working with a single PayPal account, so you won't be using SUBJECT at all. You'll use the credentials like you are already.
That said, I'm not sure I'm following you entirely what trying to send to different emails. I don't understand the end goal with that..?? The API credentials are what are going to tell the system where to drop the money, or pull data from, or whatever.
If you're just trying to get different logos to show up during checkout you can do that with parameters in your standard button code or API requests.
Let me know if that helps or not. Again, I'm not sure I'm understanding what you're after here.
I am developing an application where I have a section only for paid users where they purchase for the section using the in-app purhcase system in iOS. I know that I need to keep track of the purchase history myself, and this is where the problem begins. I have a database and I am capable of storing users in my database, with a web service interface. How can I create a system where a URL is pinged only when a user has made the purchase.
As an example, I have the URL:
http://example.com/registerUserPremium/userid=123456
How can I get this to be called only when a purchase is made? The most elegant way seems like Apple pinging the URL with a special user ID upon purchase, but I can't find a way of doing it. It is obviously not a solution to make the user call that URL within the app, as it can be cracked/pirated. What is a good way of providing such a mechanism that is piracy-proof. My service is web-based, so if I can get this part done, the rest relies on my server-side mechanism (the user will just send a special key that is stored in its keychain, to the server) so I'll be able to finish the project. In short, I need a way to call a URL only when a purchase is made. What are some possible solutions?
Thanks,
Can.
I see two solutions:
"Server product model" (doc): the appstore contact your servers every time a user makes a purchase. In this case you have all of the information right away.
"Builtin product model" (same doc) in which the application gets the receipt from the appstore. In this latter case you can contact your server special URL, providing the receipt information, and the server can verify that the receipt has not been tampered with asking the app store to verify (it's a simple post, see here).
I am working on an app in iTunes connect for a client, under their iTunes connect account. I want to add myself as a user so that I can get email notifications of updates in app status. When I try to add myself as a user I get the following message:
The email address you entered already belongs to an iTunes Connect account. To continue, enter a different email address
I am using this email address on my own company's iTunes connect account, but not on my client's account. How can I add myself as a user?
#sarnold Turning your comment into an answer because it worked for me.
Two Separate Websites
Apparently for historical and organizational reasons, Apple operates their developer and app store business in a bifurcated manner.
developer.apple.com
The web site for all the technical resources, including documentation, WWDC videos and such.
itunesconnect.apple.com
This completely separate web site handles the business end:
Contracts, banking, payments.
Uploading your finished app.
Defining your In-App Purchase products.
Problem: Different Handling Of Accounts
The developer.apple.com site is slick in that a programmer can have a single Apple ID used to join multiple developer accounts. She may work for three different companies, and be assigned a role on each of those companies’ Developer accounts all on the same Apple ID. When she logs in to the Developer site, she is presented with a popup menu asking which of the three companies’ Developer accounts she wants to access during this work session. Nice.
The problem: in iTunesConnect, not so nice. In iTunesConnect, the "admin" person cannot assign existing Apple IDs as members with a role. Very strange. The admin is forced to create a new ID for each person being adding to the team. That means the person joining must have multiple email address. If an admin tries to add you to their iTunesConnect with an email address already used on some other company's iTunesAccount, an error message reports that email address / Apple ID is already in use. Obviously the programming team running the iTunesConnect site could use some help from the Developer site's team. ☹
Workaround: Email Address Trick
The workaround cited by sarnold involves a feature of email addresses. The spec for email servers has a feature where you can extend your email address. You can add a suffix to the first part of your email name by appending a "+" PLUS SIGN. From what I could figure out, the email software first looks for the extended name. If no such name is found, it drops the extension and looks again. If found, the shorter version of the email address is actually used.
So if the programmer Susan wants to use her email address susan#example.com for a second or third iTunesAccount, she tells her client's admin person at Acme Corporation to use something like this as her email address: susan+acme.com#example.com. Apple will still create a needless extra Apple ID for Susan, but at least Susan does not have to bother with creating and accessing extra email accounts. The emails sent by Apple will arrive at her susan#example.com address.
Susan double-checked this would work before talking to the admin person. She sent herself an email to susan+acme.com#example.com to make sure it arrived at the susan#example.com account.
Effectively, the email servers are not fooled by the extended email address, but iTunesConnect is fooled into creating an new Apple ID using an old email account.
Basically, you can't invite other iOS devs to review your efforts seems to be the result of this policy.
I had (and have) the exact same problem... what makes me kinda like FlavorScape's suggestion ;)
What I did is something similar to sarnold's comment: I used an alternative email address (_#gmail.com instead of _#googlemail.com) and this actually created a new AppleID with this email address.
It works fine, but it would be so much better to just connect my actual Developer account to my client's.
The way it's like at the moment, I can not even access the developer resources and (most importantly) the provisioning center with the new Apple ID, so my client has to do create new provisioning profiles and stuff, which is pretty frustrating and complicated.
Additionally, it is a pain to let him test the Apps on his own devices, because of the developer certificate is installed on my Mac, not his, and I am therefore the only one (or better, my Mac is the only computer) that can install new provisioning profiles on his devices.
Is there a better way to connect the accounts and solve these problems?
Cheers,
Nils
Apple now will allow the same email address to be invited to multiple itunes connect accounts and no longer allows new emails to be added with the +. Just a word of warning to others who were doing this the original post is now out of date with Apples new policy it seems.
#knl: The problem in the original question is specifically with iTunes Connect. If you want to be able to manage the Provisioning center -- to make profiles etc -- ask your client to add you to that account. Here are the steps:
Go to "Member Center"
Select the "People" tab
Click on invitations
Select "Invite person"
in the next screen they can select your role including "Member" (limited access) and "Admin" (full access)
From apple documentation:
You can only create test user accounts using an iTunes Connect
accounts with the Admin or Technical role assigned to it. Test users
do not have access to iTunes Connect, but will be able to test in-app
purchases in a development environment on a registered test device.
Link here