Here's my problem. When I create my transaction with the classic api, I find myself giving them a unique tracking id (https://developer.paypal.com/webapps/developer/docs/classic/api/adaptive-payments/Pay_API_Operation/) that match the one I store in my DB.
But after 8 months of devellopement, I have some problem. I reset my DB, so on my end, the tracking id can be used, but on Paypal end, it can't.
So I was wondering if there's any way to delete the transactions I've made so far? That way I could re-use theses tracking ID and make sure that this time I don't delete the one I've used, but instead store them in another collection.
Thanks a lot guys!
What I finally did was to make a simple function that generate another ID if the id was refuse by paypal, and add the refused one in my DB. That way, at some point, I caught up with the paypal transactions ids and was good to go!
What we did was to just create another app in our Paypal developer dashboard.
Related
I am building a mobile app (in flutter firebase, but the answer does not have to be firebase specific). And I would like to implement a feature that notifies users whenever anyone from their contact list joins the app. This seems like a very EXPENSIVE feature.
At the top of my head, I see a lambda/cloud function that is triggered everytime a user joins and then searches a database of users and their respective contacts for the existence of the new user's phone number. To me, this solution does not scale well for two reasons: if the number of total users is in the millions and the number of users joining simultaneously is a lot.
My better solution is to get the user's contacts upon joining and then searching a database of current users contacts for any of the phone numbers of the newly joined user.
Is there a solution better than the second one? If so, what is it? If the second solution is standard, what kind of backend storage mechanism provides the best search and retrieval time for a database of users and their respective contacts?
In the case of large users ill not do first solution because that may slow the sign up process instead i will creat a cron job that runs at a specific time or periodically it will get the list of the latest users signed up that day or that hour whatever you prefer then that cron will check the new user if related to any user in the databases and send a notification right away, or a better solution create a temporary table in a database in another server insert the notification informations into the other server, creat another cron job in the second server it will run at a specific time to sendthe notification
I'm trying to make an app that sells a service, for which users pay based on the amount of time they've used it for, so I don't have a physical shipping address involved.
I want to be able to allow my users to save and then reference saved cards in future transactions. I know the way Stripe tracks a specific customer is through a customer_id, but I'm not sure how to attach a card to a specific customer_id and then reference it in future.
Also, I'm a little confused on the use of ephemeral_keys. Some Stripe tutorials talk about needing these on the server side, and some don't mention them at all, and that leaves me very confused.
This one talks about ephemeral_keys while creating a paymentIntent: https://stripe.com/docs/mobile/ios/basic#
And this one doesn't: https://stripe.com/docs/payments/integration-builder
Any help would be greatly appreciated! Please let me know if you need any more information from me.
PS: If you could also point me to some of the relevant View Controllers Stripe uses to save new cards and display saved cards, I'd be more than grateful!
The flow on https://stripe.com/docs/mobile/ios/basic includes the Customer for your payment context, which will cause the created PaymentMethod to be attached to that Customer. You can verify this after the initial payment by retrieving the PaymentMethod on your backend with your secret key and checking its customer field [0].
If you have a PaymentMethod and want to attach it to a Customer, you'd use the API on the backend [1].
You can retrieve a list of the Customer's existing PaymentMethods via the API [2] on the backed as well (again, with your secret key). Then you can pass a list of their id's and some identifying feature (last 4 digits, as an example) to your app in order to display and let the customer select the one they want to use. Then you take that PaymentMethod's 'id' and use it to create the new payment.
Ephemeral keys are usually only used with the iOS (or Android) SDK's, so when you're using the backend of your integration (i.e. the part that is running on a server somewhere and not distributed with your app) you generally don't need to worry about them.
[0] https://stripe.com/docs/api/payment_methods/retrieve
[1] https://stripe.com/docs/api/payment_methods/attach
[2] https://stripe.com/docs/api/payment_methods/list
instead of code, have more of a best practice/functionality question regarding CloudKit. Can't seem to find answers, or maybe just don't understand.
Questions:
When I save the record, cloud kit creates a unique record id, i was thinking of getting that id and storing in core data to allow specific query's on that at a later time vs entire database searches. However, once I save a record, how do i get the record id that was created? Is this possible?
What if I allow a user to report another user for some reason and thereby want to block that user from posting to the cloud until a review can be done. Is there a user access database in the cloud? if not, thoughts on how to?
Thanks all.
By default when you create a CKRecord it will generate a guid as it's ID. You can also specify your own id the moment you create the CKRecord. The it does not need to be a guid. As long as it's unique. Your save action will have a callback where you will get the ID.
Every user has it's own unique id which you can easily get. You could create a table with your blocking information. You only have to query for that yourself to implement the blocking mechanism.
A client just reported that his website to Salesforce integration is not working properly. It appeared that Account ID which is needed for executing REST queries has changed, so that I was using a non-existent Account ID.
I've had a look in the Account history log in SF, but nothing there said anything about any updates to it's ID. I am 99% sure I was using the correct Account ID before, as I always test all features before handing out the project. Any ideas how could this happen?
Thanks.
Account IDs do not change, ever*.
* unless they are deleted, either to be brought back later (Acct Id will be different) or merged into another account. It is also plausible (I have no idea about this one, I'm just spitballing) that they could change if your data are migrated to another instance (e.g. na10 -> na11)
That said, hardcoding IDs should be avoided if at all possible -- it's virtually always possible, and if it isn't it should be documented extensively and unambiguously -- because they will be different in the sandbox, where you are presumably doing your testing. You do test in the sandbox, right?
Sorry for the millionth question about iTunes subscriptions, but I still have a few doubts.
Basically I'm implementing auto-renewable subscriptions in my app and I want to make sure I got it right. Here's a list of steps to take that I came up with:
whenever an user buys a subscription, send the receipt to the server to validate it
if the receipt is valid, save it on the database
on application load, ask the server if a receipt for this UDID exists (this is to figure out if the user has a valid subscription)
if so, check if a new item has been added on the store in a date range from the subscription start date to the expire date
if any, notify the user about those items in some way and mark them as freely downloadable
Are these steps correct? And if so, why does the Apple doc say:
In most cases, your iOS client application should not need to change. In fact, your client application is now made simpler, as you can use the same code to recover auto-renewable subscriptions as you do to recover nonconsumable products. This is described in “Restoring Transactions.”Your application receives a separate transaction for each period of time where the subscription was renewed; your application should verify each receipt separately.
To me it looks like this needs some code to handle all the various cases I mentioned, instead. Or I'm totally wrong about it. Am I?
Plus, how do I know about the subscription expiration date? I can't find a way to get this information anywhere. Am I supposed to save this on my own database?
Update:
I've figured out a few things since I posted this question. Feel free to correct me if I'm wrong.
First of all I guess I'm supposed to store the length of the subscription somewhere on my own database, because as stated on Apple's docs, you cannot retrieve it in any way through Apple's web services. In fact, each subscription length has a different product identifier, so you should have a way to convert a product identifier to a subscription length.
Also, Sylvian has posted details about his implementation of auto-renewable subscriptions, so at least I know my thinking wasn't too much flawed.
Now the only problem is this: how do I know that an user has a valid subscription? I could store this information on my server, yeah, but how do I associate an user with a completed transaction? Should I save the device's UDID?
Here is how we implemented In App Purchases and specifically the new auto-renewable products at my company.
The application transmits the transaction receipt to our webservice, we return OK to the application if we handled it correctly and Apple could verify it. In that case we updated the user account (i.e. the database) to say "yes he has paid and his subscription is valid till the receipt expiration date".
After the OK for this webservice, the application reloads the account info through another webservice, and see there is a valid subscription. That was it... Until auto-renewable products appeared.
We now had to implement some CRON jobs which runs every day: every day we make a list of passes which are supposed to expire, and we ask Apple if the original receipt is still valid: the magic thing is that in their answer, there is a field latest-receipt which embeds the latest receipt. If it is not the same as the one we have, we understand that the subscription has been renewed automatically, we store the latest receipt for the next cron check, and we update the user account to extend the expiration date.
Hope it helps.
I think I found a solution. It doesn't require an additional username/password and it seems to be working.
Note: If you think this is inappropriate, please explain why in the comments. Thanks.
Basically, whenever an user buys a subscription, I validate the receipt against my server and store the receipt data in the user defaults. Then, when the app is opened, or whenever I need to check if the subscription is still valid, I retrieve the previously saved receipt data from the user defaults and validate it against the server.
My webservice just returns whether the subscription is still valid or has expired, plus some other related information such as the subscription length. To do this, it just queries the iTunes server as usual, and checks if the status response is nonzero. 21006 means that the subscription has expired.
If your app has some user management i.e. you use username/password to use the app, then you have to maintain a server to record the purchase/validity of the currently logged in user. This is applicable for normal subscription and non-consumable purchase. But... if you use the new auto-renewable subscription, then it's NOT possible to maintain multiple user in that app, because : this kind of purchase can not be done multiple times within the subscription period using the same Apple ID from the same application and I found it really annoying and finding a better solution for this case i.e where I have multiple child account in the app but I want to use the same Apple-Id to purchase a auto-renewable subscription for each account. And I think I have to use the old subscription model. Any new thoughts ?
as far as I have understand it the apple server will contact you (or the customer with his iPhone) and tell "look here I have a valid purchase for you". Inside your App you read this message and unlock the regarding content for use. The next step is to tell the apple server that you have responded to the receipt and the apple server will not show the message again.
So with a renewable subscription you get for each period a new message. Correct me if I'm wrong, please.