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).
Related
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.
I am developing a crowd-funding site (similar to Kickstarter) using the CodeIgniter framework.
I "successfully" implemented PayPal's adaptive payments using this library.
But, I'm just not sure how to correctly and securely check for succesfull/failed payments and witch data is important to save to database.
Note: it's a chained delayed payment, I am the primary receiver, and the secondary receiver is the crowd-funding project creator. The money is transferred to the secondary receiver after a predetermined period of time.
The flow I have right now goes like this:
User click to buy a reward.
I use the 'Pay' API operation to request payment (unique TrackingID included) and save the request in the database.
If the request is succesfull, I save some response data in the session (TrackingID, PayKey, amount, ...) and redirect to PayPal..
In this step the user can: accept payment, cancel, or just close the browser, so I dont really know what happens here... (recommendations?)
If the user accepts the payment, he is redirected back to my site and I use data I saved in the session to request a 'PaymentDetails' API operation to obtain information about the payment.
I save the result in database and check to see if the response 'amount' is equal to the request 'amount' (for security).
If everything went OK I update the database and connect the payment TrackingID with the user and the reward he bought.
Later (can be months later), the 'ExecutePayment' API operation is requested by an admin, and the money is transferred from us to the project creator, and we take a small fee (thats how crowd-funding works...)
Now, I'm sure I'm missing lot of things but I have no idea what:
What about the IPN API? I need it? Where it comes to play inside the flow and checks?
What I do if the user closes the browser window when he is in PayPay (out of my site).
I heard that the PayKey is valid for 3 hours, how can I 'ExecutePayment' after months?
How I handle the enormous amount of error types in the PayPal API?
Any tips or examples of others things I need to take care of? Security? Errors? Others?
Thank you very much, I really need your answer!
IPN will automatically POST data to your "listener" (which you'd need to develop) in order to automate post-payment procedures. For example, you could update a database, hit 3rd party web services, generate email receipts, etc. within IPN so that those events happen automatically any time you receive money in your PayPal account. You can also set it up to handle refunds, disputes, and other events. It's not required, but often very useful.
This is one reason IPN can be useful. IPN will be triggered whether the user makes it back to your site or not. If you're doing post-payment processing procedures within your thank you page or something like that, I'd recommend you move it into an IPN solution.
The PayKey is indeed valid for 3 hours when being used as a token. When you call Pay with an ActionType of CREATE, though, it sets up a delayed payment and the PayKey is then valid for up to 90 days.
The error information will always come back in the same format in the response. You can just log or display errors accordingly based on this standard response.
Sounds like you're pretty much on top of everything for the most part.
I have a <textarea> along with user registration information that I only want to be processed (inserted to the database) after payment (I want to keep my database clear unnecessary registrations or things like people that register but change their mind about paying for the site services)
I mean, I could use sessions but are there any other ways?
I was looking for a gateway that'll pass these variables back to me after purchase.
Or perhaps just having the gateway API.
Now, I know gateways such as paypal allow advanced processes like these but I don't want to apply to their credit checks just in case they have a reason to reject me. I don't want to depend on one gateway, is there any other gateways that guarantee not to reject my gateway needs and allow me to make advanced processes like the ones mentioned above? If anyone knows about gateways that don't need credit-type checks to be accepted I would appreciate if one could be suggested.
Note: I know some people will suggest to keep the registration data since it's only a few kilobytes even if people won't use the site or pay for the services. Call me OCD but I like my database clean and to only have relevant users/data. I will end up doing this in the end if I don't find a solution that suits my needs, so please, don't suggest it. Thanks.
If you want to use simple form based integration, you aren't going to get around having rows in your table before the users has been processed, unless you want people stealing your service. The fact you want your "database clean" is naive. Just put a registered flag and delete periodically if you are really that OCD.
You must create a auth token (random unique string), and update the database of the current user that that token belongs to that user. You then pass the user to the payment gateway and also pass along the token you have assigned to that user.
The gateway will send the user back to a url of your choosing, along with the token you have assigned to that user. At this point you update the table for that user with that token.
Only you and the gateway know about the token, the user only sees it if they get a successful charge.
If you don't do this, anyone can find the url the gateway sends on successful charge, and just load it themselves, giving them free service.
Alternatively, you can use deeper integration, were you do a web service call to the payment gateway, if it succeeds, you update your row, if it fails, you don't. This subjects you to onerous PCI compliance regulations. Trust me you don't want to delve into that. Just avoid it and do not let your systems see any CC information.
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.
I am developing a website in PHP that accepts PayPal payments. It uses the IPN from PayPal and has a custom payment template etc etc. It all works great through the Sandbox server but when it comes to showing my client, I don't want to have to tell them to login to/create a Sandbox account, create a buyer account and make a payment - he hasn't got time for that and probably won't be able to do it.
Therefore, my question is - is there any simple way that I can show my client the PayPal integration in "test mode" without him using the sandbox? I realise that I can set the transaction value to 0.01 and just test on the live PayPal server but that isn't an ideal solution.
Cheers!
Edit: Just to better explain what I mean, this is what my client sees when he first goes to checkout;
alt text http://img3.imageshack.us/img3/2545/67913734.png
As you can see, he has to login to his Sandbox account before then purchasing the item using the buyer email that he sets up. It's just confusing and totally non user-friendly.
Unfortunately there isn't a way around this problem via paypal. Their sandbox will always require you to be logged in to actually demo.
Here are the solutions I have taken especially with remote clients.
Use Skype or similar service so I can share my screen as I demo how it works. This solution seems to work fairly well, and eliminates the need for them to take the extra steps required.
When working on something I want to quick demo for a client and get their take, I have started using http://www.jingproject.com/ It allows me to make a quick video of the process. It uploads it to their server and provides a url I can send the client to watch what I did.
Wish I could provide a more elegant solution.
What I'd do is integrate with the actual PayPal live site and use real money. The great thing is you can refund the transaction (including the fees) so nobody pays anything. I believe the refund timeframe is 30 days, but there's no reason to wait too long and risk it. The added advantage is that you get to prove to your client that the PayPal integration really works.
If there's a concern with littering the seller account with test transactions and refunds then go ahead and set up a separate seller account. It's quick to set up as long as you don't expect your test account to be receiving thousands of dollars.