I would like to know if there is a way for invoking payment facebook API, from server side, without user intervention. I.e. Once the user approves one payment, server side acts by itself, without regarding (and annoying) the user for approvals for subsecuent payments.
This could apply to services which its business is based on repetition, e.g. in a monthly basis or weekly basis.
Thanks in advance.
PS: I think the only way to do this is by susbcriptions, but it limits the usage of one or more services.
I think this is not possible, I mean, if you payment method is Facebook credits then users will have to deal with payment gateway. On the other hand, if you have some business based on repetition then you will have to use Facebook subscriptions, as you said.
Perhaps you could perform something based on SOAP-WS, but I don't know if Facebook has services available for that.
Related
We are a team of completely junior developers and we'd like to know if there's a way to split incoming payments -equally- into different accounts, wether it's through Paypal or other platform.
For example, we would send a link button to the client to make the payment, let's say $100, and we would like to be automatically split into 2 accounts (50%-50%) or 3 accounts (33%-33%-33%).
Is there a way to do that?
Should we create a special type of account to be able to access that functionality? (for example I have my personal -non business- account on Paypal, should we create a business account in order to be able to have that split payment option and, from there, split it into my personal account and my partner's?)
Should we use another platform instead of Paypal?
Should we integrate the code into a website with the Paypal payment method? or can it just be a link that we send to the client, let's say, via email?
Are there easier ways to solve this (for example with crypto -binance or sth like that-)?
We are completely lost on this topic since we're just starting, so any advice would do.
Thanks in advance!!
For PayPal, after receiving the payment into a single account you control, you could (as separate transactions) send some of that amount to other account(s) using Payouts, which you can request access to. Approval may or may not be granted for your use case.
Without Payouts, a manual sending from that single account to others can be done in the www.paypal.com account interface, using the Send Money feature.
I have one requirement in which I need to develop Facebook messenger bots and implement payment for product from bots.
Has anyone experience with payment with bots and its approval by Facebook?
As I know currently it only has a receipt structured message that you can use for sending receipt. But there is no any API supports for the payment, you could either make a series of messages between the bot and customers by using postback, but it's very inefficient and stupid, also insecure. So I recommend using an external link that customers can click it and go to your payment system.
I have developed a bot that has integration with Stripe Payments (which is really fantastic btw). I created a WebView that redirects to my payment processing page. I didn't have any issues with the approval. All I did was send them a demo of how I get card information and showed them that I'm not storing any specific payment information because stripe hides the actual info and gives me a token to process a payment.
I find Bot approval in Facebook is stringent but straightforward as long as you give them the information they need. That means giving them a DEMO on how you're going to collect information and make sure that everything is clear.
Our terms and condition also have some payment terms (cancellation, refund, etc). Although they never checked it, I would highly suggest to clearly state these items on the T and C - and of course, make sure they tick a box specifying they agreed to such terms.
Good luck!
I'm new to PayPal and overwhelmed by all the possible approaches for integrating with PayPal.
As a start I want to implement one single subscription with monthly recurring payment. When the user returns to the site after fulfilling the payment, he/she will instantly be upgraded to "premium" member (digital product only - no shipping involved).
The first alternative I've looked into is the Express Checkout API, which looks ok, but is there any simpler way to do it?
Can I for example create a standard button (JS button or the form based), but still be able to verify the payment details when the user returns, using either the REST API, IPN or something else?
Any hints on best practices are appreciated.
Yes, there are entirely too many ways to solve this problem by now.
You can probably satisfy your requirements via buttons (aka Standard), Express Checkout (aka Pro) style APIs, or RESTful APIs, but there are a few gotchas to know:
First, PayPal has several products to do recurring payments; these products have functional differences and are tied to different integration styles. So (for example) PayPal's product called "subscriptions" (tied to Website Standard aka buttons) has different (and generally less flexible) capabilities than "recurring payments" (tied to Express Checkout) which in turn differs from "billing agreements" (tied to REST APIs, although the term "billing agreements" is also used in the express checkout recurring payments product). Oh, and there's another similar product tied to the Adaptive Payments suite of APIs.
Confused yet? Sorry. But it is important to determine whether the specific product you want to use will satisfy your requirements first before you do any integration, or you might end up redoing that integration work later (and potentially have to migrate customers, if you have already opened your business) in order to get access to specific features of another product later on. E.g., the subscriptions product has very limited ability for sellers to modify the subscriptions after they are set up. If that is OK, then great, use it -- it's simple to integrate. If I can oversimplify a bit: the Standard subscriptions product is the oldest and most limited; the Pro recurring payments is more flexible and mature; the REST billing agreement product is the newest, very flexible, but not yet as widely used; it may lack a feature you need today, but is the most likely to be continually improved going forward. I would not personally recommend the Adaptive product, although it also has its benefits.
Now, to your integration question: fortunately all these PayPal products can use IPNs. Unfortunately, IPNs are not instant. They generally arrive quickly (1-2 seconds) but delays can happen and it is quite awkward to be unable to process the customer. I would use IPNs only when shipping physical goods, not for immediate access to digital goods or in other cases where customers are waiting for a page from you. Fortunately, each of the other methods has a way to instantly determine the success of a PayPal action without waiting for an IPN:
Website Standard Payments will include GET or POST variables when it posts the user back to your site that will tell you about the outcome. If you use the Payment Data Transfer feature, these variables will include signature information so that you can post them back to PayPal & PayPal will verify their validity (so that a would-be thief could not fool you by engineering a post that looks like a PayPal success redirect).
The two API-based methods are even easier: the APIs themselves return all the information you need in the API response. So wherever in your code you make the call to create the subscription/agreement, if you get back a success then do your work to make your user premium.
There is the odd case of a user successfully paying and then getting "lost", as it were, e.g. the redirect failing/browser closing before they return to your site, or your site choking while trying to turn on the user. For this reason many people advise using IPNs, which PayPal will attempt to redeliver until you verify them back to PayPal. Not a bad idea, depending.
And of course you can call search & get details type APIs to get information about your transactions & agreements at PayPal -- although again, you will need to integrate with the right API that matches the product you are integrated with (e.g. Standard-based subscriptions won't show up if you ask the REST interface for billing agreements).
Hope this helps.
I'm using paypal to make my users able to payout their credits, which they can earn on my site. So i am actually buying my users efforts. As i have up to 200 payments per month, i would like to know, is there a possibility to send payments to my users via paypal api?
If yes, which methods should i use and what should i take care of? I possible i would also take a ready to go implementation in php.
I tried to check the documentation of the paypal api, but it was to complex, so i did not find any solution.
If you'll be submitting payments to 200+ people at the same time, the MassPay API would work nicely for you, but you'll need to call PayPal to request it and get it specifically approved on your account.
If the users will be doing this on their own, one at a time, then you'll want to look at the Pay API, which is part of the Adaptive Payments platform.
You can use my PHP class library for PayPal to make the API calls very quick and easy for you regardless of which method you end up using.
Is there a way to use the paypal API to send basic details of a payment without actually creating the payment itself? What I mean is, I'm working with a non profit organization that does not currently employ SSL. They want to use paypal to accept donations, but they want their own branded form on their page, they don't want to use the simple donate button. I had thought I might be able to send basic details, such as name and address along with the amount they wish to donate and a few other details using the paypal API, and then have the actual payment information processed on paypal's secure servers. All the examples I can find on how to use their API however are creating complete payments and sending them to Paypal, something I'm not able to do for obvious reasons. Short of employing SSL, something that we should probably do anyways, and capturing a complete payment, is there a way of sending just select information over the API and handling the rest on paypal's end?
If you want to control the form itself you don't have any choice but to go SSL. Any other route would require sending the user to PayPal, where you would no longer have that control.