Does anyone have any idea of the average Adaptive Payments application approval time at the moment? It appears there may be a backlog as we've heard nothing from the moderators and it has been over 15 days (their usual timescale apparently). Our case is a crowdfunding website built on CodeIgniter with the Adaptive Payment gateway installed and ready to go live when we are given application approval. Our site has been active for 6months using other methods via PayPal, but it's time to move up a notch.
It depends on the permissions your application is requesting; less restricted permissions usually goes through quicker.
Even so, check with PayPal Developer Technical Services at https://www.paypal.com/dts/ if you're looking for an update.
Related
You need to move your apps to bidding before the deadlines so they can continue monetizing with Audience Network.
after this message came to my dashboard I click (Move apps to Bidding) button and did select (No mediation platform -Audience Network only) option. As I am not using any other ad platform.
But the problem is, After doing this that notification is still on my Dashboard. Why? Do I have to do anything else?
you need to perform bidding it is now mandatory at least one ad must that perform bidding
you can use any platform for performing this
without bidding ads are not shows in your app.
I hope you can understand it
Thanks.
I have an application for various platforms. Let them be iOS, Android and Windows. In order to use a app, a monthly fee needs to be paid, but it just needs to be paid once in order to use all platforms. It is the same as with Spotify, so by paying once, every platform can be used.
According to the guidelines of Google and Apple, I need to offer In-App Purchases for the monthly fee. The system is connected to user accounts, which are managed by a server, which is in my control. I am storing the subscription data of users, so if a user uses the In-App Purchases on iOS, the information is transmitted to the central server in order to unlock the Android-App as well (in case it has been paid on another platform already)
The problem is the following scenario:
A user has a valid subscription which has been payed via Google Play. The iOS and Windows apps are unlocked as well. Now the user uninstalls the Android app, goes to the Google Play website and cancels the subscription. In the current scenario, I am not able to detect this and the subscription will be valid for all other platforms.
The question is:
Is there any pattern to circumvent this problem? Spotify and co are solving this issue as well, so there must be a solution for this
Well, the server that handles the authorization of the user (that is, your server) should query the Google Subscription API, to check if the current subscription is still valid. Each SubscriptionPurchase Resource contains information about when the subscription expires.
(see https://developers.google.com/android-publisher/api-ref/purchases/subscriptions)
For Apple, the same stuff applies: You will get a receipt, and with that receipt, you can query the server at any time to check if that subscription is still valid.
There is a slide which summarizes these points and the pitfalls very well: https://speakerdeck.com/rosapolis/the-recurring-nightmare-cross-platform-in-app-subscription-purchases
Bottom line: You won't be able to make that happen without a server that does the communication between the two stores. It comes with issues, though, as the slide shows.
Bonus: The talk from which the slides are taken is also on Youtube
I am currently using Kinvey only for the business logic. Everything else I am using other services. It seemed that I must be logged in to use business logic so I made one account and made the user register to that account when opening the app. I am confused if that will be an okay approach since I believe I saw on another post that after so many downloads, it will raise a flag on Kinvey's side. Is that true? I also just saw these images in the users section and am not sure what this means.
[
[
To answer your question about pricing, you can review our pricing plans at https://www.kinvey.com/pricing/.
Kinvey monitors customers in the free developer plan to check if their usage exceeds the limits. We do this by checking API calls per month, number of active users, data/file storage used etc for your kid - not by App Store downloads.
If that happens, Kinvey support or sales will reach out to you to help you transition to the next pricing tier or help you to reduce your consumption with optimization or other options.
Your queries about master secret, authentication are best answered in this Kinvey security guide: http://devcenter.kinvey.com/rest/guides/security
Regards,
Wani
Kinvey Support
I am using the Plaid API for iOS to write a program which accesses banks accounts after authentication and displays the transaction data.
I need to know if it's possible to transfer funds between accounts (checking to savings) and how.
I know acorns uses the same API, and they are able to transfer funds, and Plaid's site claims "Authorize ACH payments in seconds based on the information users know in their heads. No need to know account or routing number. No need for micro-deposits."
But is there documentation on how to move money on the site?
Plaid does not move money via their API.
UPDATES
Dwolla now provides a white-label solution that basically does this all for you. Combine Plaid and Dwolla, and you're basically golden for payments in the US now.
Disclaimer: I co-founded a company that is a customer of Dwolla and one of their first white label customers.
Original content
Moving money with the credentials that Plaid provides requires using the Automated Clearing House (ACH) process in the US.
What won't work
Ripple Labs (currently under federal investigation), Dwolla, BitPay, etc. all require proprietary authentication with their own platforms before they will move money. You can't use them with the routing and account number that you get from Plaid. You have to adopt their entire system...or nothing.
What will work
Plaid's API provides more for you than those other APIs because you have the routing and account number. This allows you to directly enter into the ACH system yourself. All you need to move money is the senders routing and account number, the receiver's routing and account number, and the amount. Plaid gives you 2/5 of this already.
But you need to move the funds. Using an ACH processor (like Vericheck - I was a customer), you can use their API to send money to an account. Or a bank (like Silicon Valley Bank - also was a customer), where you can generate and upload a NACHA file with the instructions.
What you're in for
Compliance and banking laws are strict. Get a good lawyer to help explain what you're up against. ACH processors will want to do comprehensive background checks on you and your business. Banks will require you to deposit a portion of your proposed transactions to cover STOP payments (when a user tells their bank to cancel a payment, like voiding a check). You may have to register as a money transmitter (a small $1M in filing, registration, and legal fees for all 50 states).
Moving money is still difficult to do on behalf of a user, but if you're willing to put in the legal work, the programming is pretty simple!
Plaid's API actually will give you routing and account number information and/or transaction data with cool info like GPS coordinates of transactions but I believe when I spoke to them they explicitly said that they don't provide money moving services in their API.
I've been looking at Ripple Labs, Dwolla, BitPay, etcetera.
If you have any recommendations about getting Plaid and Meteor working well together, then I can add you to a Cloud9 workspace and would be delighted to learn. :)
Plaid recently signed an agreement with Stripe. Stripe allows you to move funds via ACH through their newly realeased API: https://stripe.com/blog/accept-ach-payments
This is very similar to what companies like Peloton Technologies Inc. have been doing in Canada for EFT since 2010. EFT is what most parts of the world refer to as ACH.
Plaid provides Stripe with a higher possibility of being able to instantly verify a bank account, otherwise they fall back to the old Paypal 4 day verification processes of issuing a couple of transfers and waiting for the users to verify the amounts.
The pain of waiting on the user and the fact that 7 out of 10 times a bank account is entered wrong is what has probably prevented Stripe and other companies entering this space until now.
I want to set up a Windows Azure account.
I'm an MSDN Subscriber so I get it for "free" the first 16 months.
Still, Microsoft want my credit card number just in case I go over the free limit.
In theory, this means I'm writing a carte blanche to MS to bill my credit card.
I want to know if anyone has been using Azure and if there's anyway of setting it to simply stop working if it gets near the cap where it would start to cost me something??
Today, there are no usage caps you can place on your account. Regarding the credit card and carte blanche ability to bill you: you'd only be billed for overage beyond the "free" stuff. Microsoft recently instituted an email-alert feature that lets you know when you've used 75% of your available resources. I believe that went live a few weeks ago.
Simply put: you get 750 compute-hours monthly (metered on a 1-hour boundary). This gives you enough hours to run a single, small instance 24x7, as there are just under 750 hours in a month. If you leave two instances running full-time, you'll go over your allotment and be charged.
If you're just learning, the MSDN account is fantastic. Just remember to delete your deployment at the end of the day (or when you're done trying something out), instead of letting it run 24x7. With a bit of prudence, you'll easily be able to test multi-instance applications and avoid ever being charged.
You can also log into the billing portal from the Azure portal. This shows a very detailed breakdown of your monthly usage, and with a quick scan you'll see how you're doing regarding compute-hours.
I keep mentioning compute-hours but not storage or bandwidth. Unless you're doing some extreme development, I doubt you'll run into any storage or bandwidth overruns. Same goes for SQL Azure - stick with Web Edition databases (and only 3 databases) and you'll have no issue there.
I wrote two blog posts that might also be helpful when thinking about how to manage cost so you don't get charged:
The True Cost of Web and Worker Roles
Staging and Compute-Hour Metering
In addition to David's answer, I would also suggest maximizing your use of the local Azure runtime that comes with the SDK. You can create web & worker roles and blobs/tables/queues. Iterate there until you are happy with how everything works - then publish to the public cloud.
There is no charge for the SDK or the local runtime.
The December 2011 release of Windows Azure introduced a much revamped billing portal which, amongst other things, introduced the ability to cap spend on introductionary accounts and MSDN accounts.
Whilst you still need to provide credit card for your MSDN Account, all accounts are automatically created with spending limit of $0; a limit one can remove from the billing portal.
See - http://www.brianhprince.com/post/2011/12/20/New-Sign-Up-for-Windows-Azure-and-Spending-Caps.aspx