I want to make sure I am using the correct api before investing a bunch of time understanding/learning it. I want to use paypal to allow users of my web application to charge other users.
A user (user A) will create a fee;
A different user (user B) will pay user A via my web application. There would be many users Bs;
The web application is independent of users A and B;
The web application would not store the credit card info (hense paypal).
Eventually, I would like to add the ability for user C to create a form and add a fee to the end of the form for user A to pay. user A would then charge user B their portion of the fee charged by user C to user A.
I have not done a lot of homework with the api but I am hoping to use curl and/or php.
Additionally, I have been looking at stripe. It seems like a far more simple api but has limited capabilities.
The best solution is to use Adaptive Payment. However Adaptive Payment in PayPal is open to a selected merchant. If you wish to use that, I suggest you to file a ticket to their MTS and they will assist you further on this.
Contact them here.
Related
I am developing an LMS in which I have the following scenario.
A teacher will create an account now different students can see the subject offered by the teacher and lets suppose one of the student buys a subscription for a subject offered by the teacher.
Now when the student will pay, the amount will directly go into admin's account(not the teacher).
Now the admin can release the payment whenever he wants from the backend, in this case using paypal I need to have all the information like
API_USERNAME
API_PASSWORD
API_SIGNATURE
API_ENDPOINT
Now the logic I thought of so far is I will get all the information of teacher while registering i.e given above, and I will also have the admin information of paypal, when the admin will release payment, I will use the details from admin and make a payment in background and transfer it to the teacher's account!
now what if the teacher made a mistake in one of the above information? i will no doubt receive an error on the backend that I can display but what if I can test the user's above given information while registering that will confirm that there will be no issue in transferring money.
so my question is can test user's paypal information somehow? or is there any better logic to my scenario? this is a big project for me and I would appreciate any sort of help!
Thanks in advance for any help.
I would suggest using paypal's new marketplaces api for this type of scenario. I believe it's still in early access so you would have to request access from paypal.
With this solution, you are able to incorporate an "on-boarding" process in which when a teacher registers, you also have them grant you access to accept payments on their behalf.
When a student pays for a course, you would then complete the transaction using the teachers paypal account and set the status to "DELAYED". A delayed order status tells paypal to hold the funds before transferring them to the teachers account. To disburse the funds you would then be able to login to your admin interface and make a call to the api which tells paypal to release the funds to the teacher.
If paypal is not a prerequisite and you are only looking to accept payments via credit card, you can also accomplish this scenario using stripe, which in my experience is a much more straight forward process and is readily available without the need to request permission.
With stripe you have a similar onboarding process when a teacher registers. If they do not have an existing stripe account they are prompted to create one, then allow your application access to accept payments on their behalf.
When a student pays for a course, you would save their payment method(information is stored on stripe and you are issued a reference token) and alert the admin that a purchase is pending approval. The admin would then approve or deny the purchase. It is at this stage when the students payment method would be used to create the charge.
Hope this helps.
I have a website coded in PHP that uses paypal buttons/IPN for subscriptions.
The method is limited and I need to replace it with the REST-API.
What the system needs to do:
Accept new user recurring-payment subscriptions
Be able to change plan pricing for new users
Be able to change plan pricing for existing users
Change subscription plans mid-subscription(If a user upgrades from pro to master the price goes up, and the opposite way it goes down).
The price difference between packages is 5$
Give periodic discounts for a limited amount of months.
The questions:
1.) What is the equivalent of recurring-payments in the PHP-API or REST-API? (I'd rather it auto-charges and notifies my IPN if possible)
2.) How can I automatically refund/charge an additional amount when the user upgrades/downgrades in the middle of a month?
3.) Is there a standalone PHP control-panel that can connect to the paypal API to manage the subscription packages + sales?
Thanks in advance!
If you are looking to use REST APIs, the best place to start is going to be at the REST API docs. For your situation, you can use the vault to set up a recurring payment system. You could also use the future payments API, but you will need to make sure you buy DPRP for your account. Contact PayPal Customer Support to enable DPRP.
With the Vault API, you can just create one time payments over and over with the token you get when storing a credit card.
There is an in-depth walkthrough using the SDK on the PayPal PHP SDK Wiki.
To do refunds, you can use the Refund REST API. All this assuming that you would be writing scripts to detect your user downgrading/upgrading. You would just need to store the amount they are paying each month in your DB.
There are some shopping carts out there that are implementing REST APIs. You might need to google search for something like that.
Hope that helps and gets you started in the right direction!
Is there anyway to do the following using the Paypal APIs in PHP? I can't seem to find exactly what I need.
We are a merchant - we have several businesses who list their goods on our website.
Customers will need to pay for these goods using a credit/debit card. We don't want to force Paypal use/registration - in fact, we don't really want the customer to interact with Paypal at all.
We'd like to create a payment form where they enter their credit card details - we would then use the API to pay this directly to the business' Paypal account using their email address.
Using the REST API I've been able to do this to an extent - the only problem with this is that it doesn't seem dynamic i.e. I can't set the Payee email address to receive the payment - it's linked to my account via the ClientID and ClientSecret. Obviously this is not what I need - I want to pay into the account of the owner of the goods, not mine.
I've seen 'Guest Payments' mentioned but that seems to require the user being redirected to Paypal - something I'd rather avoid.
Thanks in advance.
I don't think the REST API is quite ready for what you're doing. The Classic API will handle it with no problem, though.
If you don't want any interaction with PayPal at all then you'll need to use Payments Pro, which allows you to tie credit card payments directly into your own forms via HTTP request/response with PayPal (no redirect or iframe).
Each business would need to be signed up with their own Payments Pro account, and then they would Grant API Permissions through their PayPal account profile for your app to make API calls on their behalf. Once they've done that, you just pass their email address or PayPal merchant ID into the SUBJECT parameter of API requests and it will use their account accordingly even though you're still using your own API credentials.
The Permissions API allows you to automate this and tie the grant permissions step directly into your app so business owners can do that quickly and easily from within their profile or during signup with your site. This works with auth tokens, though, as opposed to email addresses and merchant ID's.
We've integrated Paypal on website of client for accepting payments.
All is fine.
But client wants to be able to pay users of his website back if they have earned some bounces/scores etc.
By now we have implemented such system:
If user of website should get paid - admin of website gets notification about it in admin panel
Admin looks manually at data of client and decides whether he pays or not (pressing approve or deny button)
It looks so:
Client is not satisfied with such system, saying it will get tedious and boring business when he gets many users (unlikely, but this is not the point).
I wonder. Is it possible somehow to automatise this process? He would like only to press "Approve" button and user should be paid immediately.
At first I've thought about using the same code that I use for accepting payments:
But when I accept payments, I use address of created shop. Usual users of paypal don't have shops. Well, this is all pretty confusing.
Any links or advice are appreciated. Because I'm not sure whether such thing is possible or good at all or perhaps I should say client that it can't be done.
Thanks in advance.
You can send a payment programatically using MassPay or Adaptive Payments (Implicit Payments). Either of these methods is a little more advanced, and you have to make an API call to the PayPal server.
MassPay has some restrictions US or CANADA business accounts only.
AdaptivePayments requires the account to go through an application process on http://developer.paypal.com and http://apps.paypal.com
I am currently building a hosted Billing CRM System in code ignitor. Dwolla's low fee structure is highly appealing to me as a business owner, and may appeal to my customers as well, but I can't find supporting api documentation to confirm that it can do what I want it to do. Does anybody have the expertise to answer the following for me?
My system has 3 distinct levels of user, Super Admin (me) Organization Admin (superadmin's customers and revenue source) and Organization Members (organization admin's member/customer base and revenue source) I am currently building out choices for merchant processing gateways for the the organization admins to choose from as their billing infrastructure at organization account setup. I have already built Authorize.net, paypal, and stripe. Each of those services offer an API driven way for me to allow customers to "store" a default payment method on file with my payment system, and to authorize my system to take automatic payments on their behalf from that method of payment based on the chron jobs and parameters we set up.
I would like to do the same for dwolla, can I leverage the dwolla API to allow my users to create and store a default payment instance, and generate an applicable payment token that my billing system can then use to process future variable payments without end dwolla user's continuing input?
You would need to code all of the logic into your web app, but it is definitely possible using Dwolla's REST API. You would need to store the users' authenticated API token, their PIN number, and the account ID that would be their default payment account - all of which you could identify when they authorize your app to use their Dwolla creds.
I would consider a serious review of your app's security if you are storing all the required info to create a transaction on someone else's behalf - as most of those other services handle that stuff for you.