I have been following this page in the documentation to create a PayPal checkout integration for the purpose of allowing visitors to a site to make donations: https://developer.paypal.com/docs/checkout/integrate/#6-verify-the-transaction. It seems that the more simple donations buttons cannot be used, as it is a requirement that donations are saved to a database table.
I have so far implemented all of the integration up to some of part 6, which verifies the transaction on the server. The code provided on the page (I am using PHP) is not clear and all of the examples of server side validation that I can find refer to purchases, which do not apply to donations. However, even without this, in sandbox mode the integration appears to work. Would this also work in live mode without server validation (and there is no concern of a third-party editing "prices", as this is a donation, so why not let them pay whatever they like?)? If server validation is necessary, what resources are there that exaplain/demonstrate how to do server-side validation of transactions for simple payments (e.g. donations) that do not involve purchases?
Thank you for reading.
Per your own requirements, you want it to call your server after capture, so that it saves a record of the transaction in your server. Everything else is optional, and as you mention may not be needed for any purpose.
Related
I need to add payments to a website I'm working on and I'm not sure what to do. On the website, users will be able to purchase virtual points. So once they pay, their account will be credited with x number of points.
I came across this tutorial on IPN http://phprocks.letsnurture.com/paypal-ipn-with-php/ which I used, and was able to do a few tests using the PayPal IPN simulator(https://developer.paypal.com/developer/ipnSimulator). Everything went well and the user's data was saved to the database after the "payment".
However someone suggested another way to handle payments. Using this http://blog.scrobbld.com/paypal/protecting-your-payments-with-ewp/ tutorial which encrypts the payment.
In the second tutorial the author mentions this:
"If they use Firefox, and have installed Firebug, it is more than easy to edit the DOM of the page, and post that off to PayPal instead. So instead of having the amount at 12.99 , I might set it to:"
<input type="hidden" name="amount" value="0.99">
but doesn't this if from the first tutorial take care of this aspect? Or does the encryption from the second tutorial offer more security for the payment?
// 3. Make sure the amount(s) paid match
if ($_POST['mc_gross'] != '0.34')
{
$errmsg .= "'mc_gross' does not match: ";
$errmsg .= $_POST['mc_gross']."\n";
}
So if I understand this right, I can use the ipn listener class from the first tutorial, together with the encrypted payment from the second tutorial?
Within IPN the transaction has already occurred. So if it doesn't match you can send yourself a notification, automatically refund the payment, or handle it however you want.
A secure button, though, whether encrypted or hosted by PayPal (which is how I prefer) would not show the pricing data in the button code at all, so there's no way for anybody to even make a payment without the correct pricing.
So you could use both together, but the logic in the IPN really would be obsolete if you're using secure buttons in the first place.
The key phrase in Andrew's answer is "has already occurred" (IPN).
If you can actually verify the pricing beforehand, aside from opting for encrypting things, you could use Express Checkout where data is handled server side instead of an HTML form that POSTs directly to Paypal as shown in the sample.
This way you can treat IPN more like what it really is - a "messaging" service based on events in the transaction, rather than making it part of the transaction (where you somehow need to invalidate transactions after the fact).
While "invalidating" (credit/refund/cancel) transactions do occur normally, IMHO, it "should" be because of your business rules (instead of some validation issue, like dealing with tampered data).
"If they use Firefox, and have installed Firebug, it is more than easy to edit the DOM of the page..."
Tampering with HTML form data is an inherent risk in all <form /> and all modern browsers have internal tools (Firefox, Chrome, Internet Explorer) to inspect everything it ("client-side") is involved in. That is why validation (both client and server side) are required in any time of web development.
Hth..
I'm putting sagepay into a PHP powered site.
So far I've had no trouble integrating the Form into the site, their docs are great compared to paypal (mutter mutter)
However I noticed in the dev guide for form integration, they say you can't rely on sagepay sending the customer back every time as they could close the browser, or navigate somewhere else etc.
At the same time, I don't want to move everything out of the user's cart and into an order before I know it's been confirmed / payed for - otherwise if they cancel or the transaction fails somehow on sagepay's end, their cart will be wiped out when they come back, making retrying the transaction a pain for the user, and I will have a duff order polluting my database.
So what I want to know is if there is a way to get sagepay to send a request to the site when something happens with a payment, similar to paypal's Instant Payment Notifications?
EDIT:
Or are they only saying it's patchy because they can't garuantee it, but it works enough of the time to practically rely on it?
Sagepay (AKA Protx) form integration redirects the user automatically once the transaction has completed.
For small sites, i advise my clients to always check the sagepay transaction logs (on the sagepay site) before sending out any goods.
You should be logging the order before they go to Sagepay. Then changing it's "status" to paid when they get redirected back to your site. This gives you a bit more of a paper trail to pick up any possible issues.
If you want a more robust solution. Try Sagepay direct integration. It has more requirements and is harder to integrate but on bigger projects (where you can't manually check orders) it's usually required. Mainly because users can stay on-site without having to go off to Sagepay to make payments.
Been integrating AuthNet's Automated Recurring Billing system alongside its Silent Post feature to create a paid features system inside our team's web app. The silent post feature has slim documentation, but I have come across several helpful threads on SO as well as a few blog posts authored by our members (especially John Conde's "All about Silent Post" ) to help guide the way. I have a few more specialized questions however I was hoping some of you more seasoned folks could help out with.
The Authorize.net documentation includes this notification:
Test environment accounts do not process ARB subscription transactions. If you are using
a test environment account, you will not receive these email notifications in any form. You
will also not be able to receive an ARB subscription transaction Silent Post while using a
test environment account.
I was wondering if anyone knew if this means accounts set to TEST MODE in their control panels, or does this refer to the developer-only accounts available to those working on AuthNet platforms independent of deployments? The account we are using for testing is an actual merchant account set in test mode and we're receiving silent posts for virtual terminal payments done through the AuthNet CP, but even successful ARB's are not showing silent posts.
Also - what kind of parameters can be used to ensure that a silent post originated with AuthNet? I set up an endpoint and printed out the request objects from a silent post as well as the $_SERVER superglobal - it does not seem that they send any identification other than the MD5 hash set in the CP. This is fine, but I was wondering if there would be any advantage to limiting to specific remote addresses - I assume this is unlikely as the posts probably come from a datacenter with tons of IPs allocated for the task of sending silent posts.
Also, the ARB spec only sets a subscription status to SUSPENDED within AuthNet under very specific criteria (only if the failed payment is the first rebill and if not then after two attempts on subsequent days.) Is this a normal practice for suspending subscriptions? If we would like to make one decline trigger suspension, should the logic for revoking the feature also issue an UpdateSubscription API call and set to suspension manually in order to forgo the default spec?
I was wondering if anyone knew if this
means accounts set to TEST MODE in
their control panels, or does this
refer to the developer-only accounts
available to those working on AuthNet
platforms independent of deployments?
This refers to both. Any test ARB transactions will never be processed and not generate Silent Posts. It's probably why their developer forums are riddled with questions about testing ARB. Basically, the best you can do when testing it, besides setting up a live subscription, is to:
Test the API call by using a developer account. If you get a subscription ID back you know your integration is functioning properly.
Test Silent Post by sending a simulated POST submission to it. I can post a sample form for doing this.
Also - what kind of parameters can be
used to ensure that a silent post
originated with AuthNet?
The MD5 hash returned in the silent post is a hash of a string that includes an MD5 hash value (set in security settings) that presumably only Authorize and you know. Thus, you generate a hash on your end using the returned info plus the secret hash string and compare to validate the response. Specifics about the hash can be found here.
Is this a normal practice for
suspending subscriptions?
Normal practice? Honestly I don't know. I'm not sure how other companies handle it. There's a post somewhere in their community forums where an Authnet employee explains how it works but I was unable to find it to link to it here. It made sense to me when I read it.
If we would
like to make one decline trigger
suspension, should the logic for
revoking the feature also issue an
UpdateSubscription API call and set to
suspension manually in order to forgo
the default spec?
If a subscription fails it is automatically suspended by Authorize.Net so you don't have to do anything on your end. But you do need to update your user's account in your system and suspend it (assuming the subscription is for a user account of some kind).
I need to build web application where users can sell goods.
Each user should be able to get money directly on his PayPal account.
Can you suggest which PayPal service/payment method (or other payment system) it is better/safely to use in this case?
Thanks in advance
This is easily set up (if I read your requirements correctly). You would have to create your part of the system, but that's obvious.
The rest, specifically vendor payments, could be handled all by PayPal.
PayPal could process the orders into individual accounts. You would simply have to use the same IPN notification file for each Buy Link. This IPN notification file is what PayPal uses to notify an order has come. It does not matter that it may have come TO Suzie's or TO Bob's account.
So, your notification script gets the order -- Then, your internal system differentiates the vendor and ... that's it ;).
IPN is very simple too, and they've got nice templates in various languages to get you started.
I'm sure there are alternate ways to do it, but IPN is what I personally use, combined with a back-end system. I even have another vendor whose plug-in for my product I sell. Money goes directly into his PayPal account by simply changing the recipient email in the Buy URL (or form).
Any competent programmer should be able to handle this with ease. The proficiencies would be SQL/database experience and web coding (any language). That's about it. A non-programmer could probably even learn, though needs to be careful to sanitize the input to protect against SQL injection attacks.
You can use ExpressCheckout, this means that your sellers do not need tho have Pro accounts, but login and payment will occur in paypal's popup window. You can also use more advanced integration, but this might require the merchants to upgrade their account, and this might cost them money in every month.
You also need to collect API keys from merchants and store them in a very safe location, or collect the money yourself, and pay for the merchants using paypal's API code, but this will introduce additional (transfer) costs.
You will most likely have to write it from scratch. I mean, from some bare framework.
got a question and I hope this is right place to ask :).. don’t quite understand how payment works in magento.
client goes to checkout and lets say wants to pay as a guest, so provides address etc. and finally gets to payment methods. Then I want clients to pay thru credit card. Already have module installed for gateway (bank?) of my choice. At that point I would expect users to be redirected to 3rd party page (bank hosted) where they giving all the details, only after being returned to my magento site with appropriate message.
In magento however it seems like they need to provide cc numbers and details on magento checkout page. I don’t understand if I (or the payment module I installed) need to transfer then all the credit card details to bank? I would have to have checkout page on ssl connection and static ip right?
The thing is I want to avoid touching CC numbers at any point and would love to have it done by a bank page. I like the idea of magento interface all the way without redirecting to another page though, the only problem is not sure if would be able to set it all up properly.
If anyone could explain to me possible options, what is the common way to do it and how the whole process works that would be very much appreciated.
I did my research and looked all over google and various forums still need someones help though. Please let me know if some parts of my question are not quite clear, will try to better explain if necessary.
Had to develop a payment module for DPS in NZ some time back. How this works is, you go to pay on the site and the payment module php code runs that sends off the details to an acquiring institutions payment website who process the transaction for you with the bank. In my case as I recall it was DPS NZ via some soap calls. The Soap calls contained details such as the total cost, the currency, the merchant number to identify who you are paying. The acquiring institution (DPS in this case) then takes your credit card number and expiry date and do the processing. Then, again via some soap calls back to your own magento website you get redirected back with the error code - success, etc.
DPS use soap I think, but other payment websites may use other protocols to work. The other possibility is that your credit card acquiring page could be hosted on your website and you accept the credit card numbers and do all the processing within magento to the acquirer.
In short, the process is controlled by the payment module itself. If you want to see more detail, have a look at the payment module tutorials that are available and also the comments in the magento forums. You can also look at the paypal module code.
The default architecture that Magento payment modules use involves the customer interfacing with the module and the module talking to your payment gateway behind the scenes.
Basically the customer inputs all his data (CC and all) and hits the payment button at which point certain functions are run in the chosen payment module. What these functions do is entirely up to how the payment gateway works. if the gateway talks via XML they send/receive XML, if it needs SOAP then they use SOAP and so on and so forth. This in fact is the gist of building a new payment module. Open an existing one, check out which functions are called, get rid of the code in there and substitute with your own that will talk to your particular bank/gateway.
Of course some gateways have an alternate way of operating where you send the customer to their pages, he gives them his CC data and he is promptly returned to your site. This way you don't need to worry about handling credit card data, but unfortunately the process of implementing this in Magento is somewhat more involved.
If you need to use a certain gateway then you should first check whether a payment module for it already exists. if not you can download a similar payment module, dissect it and modify it to run your code where appropriate.