Suppose i have an app and a website that offers people to sell finger drawings made on their phones.
People create finger paintings on iPhone and upload it to a website in which they can view all
of their drawings and associate prices with these drawings.
Suppose each drawing has a QR Code tied to it to identify it and its price. And i see it in real life and i want to buy it. I scan it, pay for it through paypal.
But how will paypal redirect this money to -> owner of that product set.
What i need is a system in which each transaction knows whose account the money is being directed to. Lets say I have 10 various qr codes according to the 10 drawings. This product set needs to have something associated with it so that when they are scanned, paypal money flows to that product set owner.
Also, these drawings owners/product set owners must be able to withdraw money from the aforesaid html website.
Paypal Adaptive payments option has two options for this.
Chained payments
Parallel payments.
Please refer to : https://www.x.com/developers/paypal/documentation-tools/adaptive-payments/integration-guide/APIntro
However, current iOS SDK - which is in beta status (https://www.x.com/developers/paypal/documentation-tools/adaptive-payments/integration-guide/APIntro) - does not support these features. (as on 21 March 2013)
One option is to use paypal APIs directly, or implement the flow using a webview.
Try with MPL which is also recommend by PayPal https://github.com/paypal/sdk-packages/blob/gh-pages/MPL/PayPalMPL_2-1-0_iPhone_DevelopersPackage.zip
Check the below link where I have written complete flow to integrate delayed chain payment in iPhone.
iOS PayPal integration with backend chained payments
Related
I'm interested to see if anybody is looking to integrate Woocommerce with the PayPal Here payment App? More so the importing of products from Woocommerce to the PayPal Here App. Be a great addition.
I haven't looked into that specifically, but I will be adding a "virtual terminal" / POS functionality into my PayPal for WooCommerce plugin before long. I've got it planned for the next full version release.
It basically gives you a section in the WP admin panel where site owners can easily put together invoices using their WooCommerce inventory and then process those orders accordingly. I will be including the Invoicing API's so you can create an invoice from the Woo VT order page, or you'll also have the ability to swipe a card using a USBSwiper card reader. Of course, you could also key in card data if you needed to do it that way.
The cool thing about that is even when you key in the transactions you still get your 2.2% - 2.9% rate depending on your volume because it would be processed over Payments Pro in that case. Same with invoicing or swiping.
Back to your original question, though, I'm unaware of any API or tool that allows us to interact directly with the Here inventory. They do have the Sideloader API for PayPal Here, which would allow you to send inventory (or a specific order) into the Here app from your own app in order to complete an order, but I don't think it lets you push inventory directly into the actual Here app.
On that note, what I could potentially do is build a stand-alone app that does nothing but pull in current WooCommerce inventory, and then from there you could create orders through the Sideloader API using that inventory, but it would use the Here app to actually complete the order. Seems a little clunky, but in theory, that should work fine.
If you want to contact me directly we could discuss getting this done for you.
Right at this time PayPal Here is designed to be card present, so you cannot import your products from Woocomerce into the PayPal Here App.
Here is a link to an FAQ on PayPal Here:
PayPal Here FAQ
Here is the current list of PayPal Here Partners:
PayPal Here Partners
I.e. user clicks buy, I authorize their card and wait 2 weeks and see if enough users have pre ordered a given product before charging them and shipping.
I'd like the following -
To avoid pci compliance I'd prefer to whisk users off to paypal for getting c.c. details.
progmatically reauthorizing any preorders and capturing funds is fine after 2 weeks. But for my prototype doing this via the paypal account dashboard is fine.
my app being notified when a user successfully preorders (ie. there card is authorized by paypal) in order to update my "preorder" counter on the site.
For my prototype I want to avoid as much coding on this so offloading as much as possible to paypal, even if it means I have to manually handle reauthorizations and payment captures is actually better in the short term.
Can paypal uk provide this functionality and if so which business solution is this? standard or pro?
You should be able to do this with standard; However considering that you eventually would want a "tighter" integration with your back-end systems and, it might be a good idea to start with pro itself.
Hi every one Can I buy inside my app one thing like one t-shirt,
I know In App Purchase can't works because t-shirt is a real life thing but
i dont want the payment outside the app like in safari.
I like to be the payment inside my app,registering a credit card and buy the item,
like this apps Amazon, Airbnb how the payment inside this apps works?
I've read a lot of information about that and all the people say the only way to make payments inside the app is with In App Purchase but how this apps i've mentioned works, because i can make the payment inside this apps.
There are multiple systems you can leverage out there. You could take a look at Paypal's IPN and Google Checkout.
The PayPal API is free, and here you can find a nice example on how to integrate it.
Most important is that you may not use the PayPal API for Digital goods...
and one more
I have a question about payments through an app. Are there any type of payments you can do without apple applying their 30% cut?
from my understanding, apple's stand is if your application generates any new revenue, that apple is entitled to 30% of the revenue since they are providing the service and hardware that gets you that new revenue.
we are a subscription based service (we sign customers up outside of the app either though our website or in person). we use the app to access our data in a mobile form.
we recently began offering a new service where we need to charge them per usage (its outside of the subscription fee). this is a service for existing customers and the app has not attracted a new revenue source. all services available in the app are available through our website or in person.
we sell a service and access to our database, no physical goods. the new service will be available through the application, but not used in the application.
we would process the payment on our own servers (do not use services like paypal). they can always make a payment through our website or in person. we would either store their credit card information on our servers or prompt them to enter it.
it is a matter of convenience for our customers to do a payment through the app.
will apple insist on taking their cut do you believe?
EDIT:
how do credit card companies handle payments in their apps? are they paying apple 30% per payment you make to your card? or are they an exception to the rules? does apple believe that allowing big credit card companies to accept payments w/out taking a cut help apple in the long run as an attraction?
If users pay to unlock digital content within your app then you must use In-App purchases, for which Apple will take their 30% cut.
If however the unlocked services are for 'real world' goods or they are not accessible within the app then you must use another payment method with no cut taken.
Overview of In-App Purchase
Ask yourself if you need to include the payment side of things in the app. While Apple has gotten a bad rap for taking a cut from services, a lot of that depends on what type of service you are offering. Netflix isn't giving up 30%. The big reason for this is they don't allow you to collect payments through the app. If you venture down the road of trying to skirt around Apple's in-app payment, you are likely to get burned. There are ways around it for sure, but eventually they can catch on and require you to implement IAP for signups.
There is nothing wrong with requiring users to handle the business end of things on your website. This will avoid any ruffled feathers with Apple.
I think you should use the same mechanism what Groupon is using. They collect the information from Mobile app and feed the data to there payment server and they are good to go i think.
I am new to credit card payment applications, I am developing an iPhone application which requires to take credit card payments from the user. In this application I am just providing a coupon to the user and if the user uses the coupon I just want to collect $1 from the user's credit card.
I have read In App Purchase guide but this doesn't suit for this requirement it seems since my coupons are just builtin-App products.
can anyone provide other method which best suits for my requirement or if IAPP suits for my requirement, how to approach.
some help will be appreciated.
I don't know how you are planning to distribute your app. Apple says it will reject almost any app that takes payments via anything other than in-App purchase. There may be some narrow exceptions, but you should take a very careful look at part 11 of their approval guidelines (from the link).
The easiest way is to implement in App purchase for every coupon and the in app purchase just unlocks the content(which must be stored in the application or downloaded from your server).
super easy.
But I would recommend you to implement a feature like buying credits for the app.
You can create an in App Purchase for let's say one (1$) 3, 3$) and so on. This can be send to your server(of course you need to make the billing management on your own) and the iPhone User can identify himself by an User Name and an Password to get access o their Credits and redeem them instantly in the App. In this Situation you could even extend your service by adding PayPal Payment(in an WebView inside the Application).
I Hope this helps. Good Luck.