I am working on one app. In this app to buy some non digital items i have to give access to users to do transactions using credit card / debit card. I have seen some apps in app store which accepts credit card / debit card . Those apps are Pay Anywhere , Rev COIN.
1) Can we know which third party API's they are using. 2)While using these apps do we need any card reader(another device) to swipe the card.
As well how to get those API's. Can any one help me please. This plays majority role in my app. Any suggestions please.
Doing some transactions with ZOOZ are ok . But coming to my app i have one requirement. i.e user can send order for one item and user can say expiry time(i.e in how many days product has to be delivered) at the time of offering an item payment will be done. before delivering the product user can cancel the order. whenever the order is cancelled some amount has to be deducted and remaining has to be refunded.
For example user sending request for pepsi which is worth of 10$ and expiry time is 3days payment will be done immediately. Next day he may want to cancel the order in such a case user 2$ will be deducted and remaining 8$ has to be credited back to user account. Can we do any these type of transactions using some API's.
Zooz is one way that you can do in-app payments. It's supposed to be easy. That kind of model would be for you using an app as a kind of online "store" like amazon.
If you're talking about using an iOS device to record transactions (using a single unit as a cash-register system) then you would need a card swipe add-on unless you want the customer to input all of their credit information when they pay.
Or, as jgervin pointed out you could use card.io to let the users take a picture of their credit card. The company charges you per-scan however.
Important note: Apple will reject your app from the app-store. See the linked questions.
Pay for a physical product with in-app purchase
Has anyone implemented the PayPal API through a native iPhone app?
Which PayPal iPhone SDK should I use?
So hopefully you're planning to deploy with airwatch or something similar.
Related
We are building an iOS app that uses Yodlee API's to retrieve credit card transactions for our users.
Right now, we are using FastLink API to connect.
Once accounts are added to a users profile, is there a way to filter the transactions for a specific account by credit card? (For credit card accounts that have multiple cards associated with them)
For example: I have one credit card account with 4 cards associated with it. I am trying to retrieve only the information for a single card. Can this be done?
Yes, you can get a particular credit card account by calling Get Account Details API-https://developer.yodlee.com/apidocs/index.php#!/accounts/getAccountDetails
by passing the accountId and container as creditCard.
Hope this helps.
I have created shopify app and setting up billing Api. In the App, I want to apply trial period of 20 days. I have created the charge during the app installation and send customers to confirmation url so that they can accept or decline the charge.. So I want to know that if customer decline the payment charge, then can he uses the app featurs till trial period?
If a customer declines the subscription, you still get the confirmation URL callback. Examine the charge. The status will say declined. At this point you can kill off their DB token and destroy their session. This will ensure they cannot use your App as they declined the terms.
It is one bad aspect of the whole billing scenario. I have lots of customers that are faced with a question they don't read. So they assume the trial you offer for free is activated by declining the subscription. Silly customers... still cannot operate the Internet :)
How shall I integrate custom shopping cart app with PayPal to accept indirect credit card payments without forcing buyers to register at PayPal?
There's a custom shopping cart web application and the task has been set to replace current credit/dept card payment with PayPal. The goal is to let the customers pay with their cards via PayPal. However, there are some constrains:
customers should enter their credit cards details (number, expiry date, secure code) not in shopping cart's page, but PayPal's page,
every payment must consists of authorization (blocking total sum) and subsequent capture if the ordered items are available and can be delivered,
customers aren't forced to create / login to PayPal account if they wish to pay via card.
The trouble is I'm really confused with the number of possible options at PayPal. The choice between REST API and Classic API isn't that problematic, but choosing the proper product from the whole list (like Classic API products or REST API products) isn't that obvious for PayPal newbie. Some other similar questions point to DoDirectPayment (but I don't know if it's the best choice) or suggest Website Payments Standard (I'm not sure if they're still available).
I was also considering Express Checkout, but the demo seems to force to create PayPal account.
ExpressCheckout is designed to be used in concert with a direct credit card acceptance method (such as PayPal's DoDirectPayment, or a non-PayPal credit card acceptance method), although it can be configured to also do guest payments. This is why the demos of the normal configuration handle only PayPal account creation; that's the normal usage.
One key question you need to ask yourself is whether you want to have access to the credit card information & be the "merchant of record" yourself or not.
YES: Doing this gives you the most flexibility, but will require you to go through some merchant vetting and carries some security obligations (PCI) even if you are using some solution which tries to distance you from the actual raw card numbers (e.g. collecting them via PayPal or Braintree code and immediatly encrypting & tokenizing them). In short: if you want full access to the card, then you have legal obligations re: handling that account access which technology can reduce but not eliminate.
NO: If you are content to always treat your customer's card information at arms length through PayPal, via the legal structure of a PayPal account (whether the user actually has a PayPal account or is just doing a "guest" payment on PayPal where they give PayPal their credit card for one-time use) then you can reduce your vetting & security constraints (no PCI requirements at all).
If you want (or need) access to the customer's card [YES above] then the "classic" API solutions are either DoDirectPayment (for when you collect the card info) or Hosted Sole Solution (for when PayPal collects the card info on their page). HSS meets all 3 of your requiremens above; DDP fails requirement #1.
If you can live with access to the customer & the payment but NOT the card account itself [NO above] then you can use Website Payments Standard, or EC with Guest Checkout option; both meet all three of your requirements.
All of the above solutions are not only still supported, but have tens or hundreds of thousands of integrated merchants and are the biggest/mainstream ways in which PayPal payments are handled.
If you prefer the newer products & are in the first category above (real card access, not guest payments) then you can also use Braintree or the RESTful APIs. These newer products don't yet have as much flexibility & coverage as the older products, but hey, less complexity can be a good thing as long as they have what you need. These products are generally designed around plugins for your web pages rather than entering card information on PayPal's site, however, so they don't meet your first requirement.
You can also do PayFlow (several variants) or Adaptive Payments or or or.... but in general I would advise picking either the most well-established or the new-and-growing options as being better supported & more future-proof.
Now that PayPal has acquired Braintree, the preferred integration method is v.zero. It is designed to be very easy to accept PayPal, Credit Cards and other options. (Venmo, Bitcoin, etc.)
Background
My iOS app supports multiple user accounts, but the user can only be logged into one account at a time. The app also offers a subscription service ("credits" in the form of a renewable In-App Purchase).
I'm having trouble keeping the in-app subscriptions separated to the specific user account that bought them. If a user buys credits on Account One and then signs out, and another user signs into Account Two (on the same device), the SKPaymentQueue still proceeds with the renewal process for the purchases from Account One (and, consequently, triggers the logic that unlocks those credits).
Question
What is the correct method of handling renewable in-app purchases for an app that supports multiple accounts? Is there any way to keep purchases from "overflowing" into other accounts on the same device? What else should be kept in mind?
I'm pretty sure what you're trying to do isn't possible. In-app purchases are tied to the Apple ID that purchased them. That means that if the user is logged into an Apple ID that has purchased the subscription, you are always going to be told it is available. A single user can't purchase the same subscription multiple times. The only way would be to force an Apple ID change when they change users in your app, which I'm almost certain you can't do.
I'm not sure this is the right place to ask but anyway:
I have an e-commerce platform that I want to monetize based on a percentage of revenue made (eg. a store that uses my platform has an order for $100, so I get 1% or $1, while they get $99).
Currently I offer paypal and credit card payments (via my merchant bank) to all stores on the platform (ie. all payments made, regardless of the store, are through the same paypal and merchant account). I then pay these stores per month which is ok for the moment because there are only a few stores using the platform.
Moving forward I want to automate this process and ideally have it operate in real time.
Paypal have an "Adaptive Payments" API that allows chained or parallel payments on a single transaction processed in real time. This means I can skim my 1% and pass the rest of the money along my customer in real time.
I was wondering if there is a similar real-time service for Credit Card processing*? If not, is there a bank/merchant that allow API payment access so I can automate payments per day or week? OR should I just transfer all money from my bank to paypal and use this to pay my customers?
*I realise you can process credit card payments through Paypal without having to sign up, but this is less than ideal. I want the credit card processing to happen on my page as at the moment I'm seeing about 70% of orders using this over paypal.
I was wondering if there is a similar real-time service for Credit Card processing?
No there isn't. True merchant accounts do not allow for split payments. Only one entity can receive a payment and it must be the business the merchant account has been set up for. Receiving the payment for someone else is called factoring and is against all of the major credit card issuers' rules. If a merchant account is found to be factoring it will be closed and the merchant who owns the account will be blacklist. This will prevent them from ever having a true merchant account again. Additionally, there is no way to send money with a merchant account other then issuing a refund for prior purchases.
If not, is there a bank/merchant that allow API payment access so I can automate payments per day or week? OR should I just transfer all money from my bank to paypal and use this to pay my customers?
Other then using adaptive payments, this is definitely the easiest and most straight forward way to accomplish this.