I am currently trying to find if it is possible to create a dashboard to my companies loyalty pass, similar to the one that Apple has created for their own Apple Card.
I have been able to add just a text on the card that updates whenever I send the notification, but I am looking to display more stats about customers purchases. I have not been successful in finding guidance about this on documentation, so it could be that Apple doesn't allow that yet to anyone else. Is my idea possible, if so how to add GUI elements under the pass?
Related
I'm running into a support issue with my iOS app. Certain users are trying to subscribe via an In App Purchase, but the plan options for the subscription are not showing up for them so they are unable to subscribe.
I've tested this with the following:
Apple User without a payment method setup
Apple User with a PayPal account set for the payment method.
Apple user with a credit card setup.
The subscription plans still show up for all these configurations.
Once again this seems to only be happening for a specific set of users.
James there's not a lot to go on here. As a developer you are responsible for displaying/merchandising the subscription. There's no way to be helped until you can provide more information.
I am using flutter to build my first ever app.The app is designed for users to be able to buy and sell products amongst each other and I would like to set up functionality to have payments go through the app. There does not seem to be a lot of documentation on this and I really don't know where to start. Can anyone enlighten me of what the easiest route to go down will be? Square? Stripe? Are there any good start to finish tutorials out there? Thanks in advance.
You can definitely do this with Square using our In-App Payments SDK! I would suggest taking a look at our example to quickly get started: https://github.com/square/in-app-payments-flutter-plugin/tree/master/example This will show you from start-to-finish how to take a payment from a customer within your Flutter application.
With that said, to comment on how this would behave: Essentially your Flutter application would be able to open a "card entry" screen, which would allow a customer to enter their card details accordingly. The result would be a nonce, which you can then easily charge on your backend. The example shows all of this, I just wanted to quickly explain the high-level behavior.
For more information, I suggest taking a look at the Square Developer Docs for our In-App Payments SDK. Of course, if you have follow-up questions, don't hesitate to follow-up with us over in our Slack channel: https://squ.re/2Hks3YE
I'd like to develop an app that shows in-app ads. To remove the ads, I'd like to present the user with a list of non-profits that they can make a one-time donation to. I'm not sure what the best way is to implement this.
ApplePay supports allowing one-time payments to non-profits, however I'd like this functionality to work more like in-app purchases where the user can restore their purchase if they use the app on another device rather than have to pay a second time.
I looked at ApplePay's documentation and it doesn't appear as though there's any sort of built in behavior for this. Also, it's unclear if I can have one app make payments to multiple different non-profits.
The documentation for In-App Purchases makes it look like the payment would have to go to the developer account linked to the app, but I'd prefer for the payment to go to directly to the non-profit rather than to my developer account so the user can get a guarantee that their money is going to the right place.
Does anyone know if there's a solution out there for behavior like this? I'm open to using other payment system's besides Apple's as long as there's a mechanism to validate their purchase if they install the app on a new device, preferably without having to log in, and the money goes directly to the non-profit.
I'm in the process of making an iOS app. This will be my first iOS app. It is based on making phone calls using calling cards. The customer will buy the calling cards in the real world and they will get a pin which they would need to enter in the app. Through this pin they will get the credit to make the calls.
I went through the submission guidelines. Usually when a app requires the user to buy something from with-in the app, then IAP is used but here the purchase is being made in the real world, without using the app. Do I need to integrate IAP into the app? Will Apple accept the app into the app store?
Any help is appreciated.
Thanks
As your requirement suggest
The customer will buy the calling cards in the real world and they will get a pin which they would need to enter in the app. Through this pin they will get the credit to make the calls.
It means you are dealing with somewhat physical stuff like customer will buy the calling cards in the real world so at that time he/she must have to pay something for that. so there is no need to integrate IAP in this scenario.
IAP is only for the stuff/service that will provide within the app by service provider. for physical service you can exclude the IAP. if you give proper description and explanation to apple when you submit your app for the review apple will definitely approve it
hope above answer will help you
I think you're in a grey area because it all depends if Apple thinks the credit is consumed in the app. If considered consumed in the app, you may have a problem. Try to find another iOS telephony app that uses cards, one that's well know enough to be sure that Apple may have had a good look.
If you'd give users game credit with physical cards, it's clear that Apple would not allow this.
What makes this a grey area is the telephony side: If it's a VoIP app you could argue that the the credit is (partly) consumed while using the app. But you could also argue it's outside the app on the VoIP/telephony network.
If it's not a massive investment, I'd try the calling card route first.
You could try ask Apple, but you'll probably won't get a clear answer as they want to see the app first. I've tried this a few times in the past. Makes sense because they don't want to make promised based on what you write in an email.
I have a client that needs to have its volunteers purchase an IAP (A data package that is downloaded), then somehow reimburse them. The problem is that there is no easy way to do this that I think Apple will approve of. Especially for over 1500 people. I've come up with several ways of doing this with their pros and cons, which one would be best to implement and does anyone have any other suggestions on how to do this?
1) Have the client send out iTunes gift cards via email. The IAP is $7, and you can't send a gift card less than $10. Also, they would have to send them one at a time, there is no way to send bulk. Not going to work
2) Create gift codes like iTunes gift cards. My client can purchase codes in bulk via IAP (so Apple still gets their money), and store them on my web server securely. I can then implement a system to send all the codes to a single email, or individually to multiple emails. Then the volunteers can use the codes to unlock that single IAP. This would be more work on my part, but easier for my client. Something tells me Apple probably would not approve of this method.
3) Create "Credits" that the client can purchase in bulk via IAP (so Apple still gets their money), then gift either the credits or send the IAP info itself to the volunteers via a p2p bluetooth connection created with game kit. This would be harder for the client, as they would have to send each "Credit" individually. But I think Apple would be more likely to approve this.
4) Have the client send me a list of UUIDs for each of the volunteers devices. I add the UUIDs to a secure list on my server. During the purchase the a check is preformed to see if the devices UUID matches one on my server. If it is, they are marked as "all ready paid" and given the IAP data. I don't know about this one, as the only way I can see the money transfer happening is myself getting paid directly, and Apple being left out (So they probably wouldn't approve of this. I have no problem giving Apple their 30% if I could find a way to get that to work with this.
I'd go with Option 5, and create my own IAP system. Much like Option 3, but bypassing Apple all together. Add a Custom URL Scheme to you application, give it to your client to distribute. When your app is launched by its Custom URL Scheme have it open to a promo code entry page.
Your client would be able to purchase/create codes as necessary via a website that you set up for them. You would then store the codes (or create an algorithm to check generated codes against), and validate the codes as the users enter them.
Then your clients users would enter their unique code and have everything unlocked/downloaded as needed.
I have done a similar set up with promo codes to unlock the full version of my applications so I could create my own promotions, without making the upgrades free for everyone by removing/altering the IAP.