I am successfully using Authorize.net CIM via PHP to charge and then recharge credit cards using their xml api.
The information which I need when I want to recharge their card is
their customerProfileId which I use to get their customerPaymentProfileId
and then am able to charge up to the amount which has previously been authorized.
Is the customerPaymentProfileId static? As in, do I only need to retrieve it once and then it won't change 'ever' change?
Am I able to use the bulk upload feature of authorize.net as described at:
http://www.authorize.net/files/uploadguide.pdf
And if so, where should I be putting those fields?
If I am unable to use the bulk upload feature, would a solution be to just loop through the transactions that I have under my current PHP script, or may there be complications that would be introduced by doing that.
Is the customerPaymentProfileId static? As in, do I only need to retrieve it once and then it won't change 'ever' change?
Yes, it is static and will never change. If it wasn't this service would never work.
Am I able to use the bulk upload feature of authorize.net as described at: http://www.authorize.net/files/uploadguide.pdf And if so, where should I be putting those fields?
No.
If I am unable to use the bulk upload feature, would a solution be to just loop through the transactions that I have under my current PHP script, or may there be complications that would be introduced by doing that.
That would be exactly what you want to do. CIM is typically paired with a home-grown automated billing system. Usually to handle recurring billing with varying payment amounts. Those systems will do this very thing.
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 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!
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'm trying to link my 3rd party shopping cart to PayPal, and in the process I'm finding that my variables are extremely exposed, such that, if someone uses, say, Firebug, to manipulate the values of my variables, they can change the cost of the items in the transaction.
I'm very new to online carts and shopping, so my question is how do I keep this layer of exposure away from users and secure for the website?
The answer is in the Instant Payment Notification service.
Upon completing the transaction, PayPal notifies you, in a separate process, of the payment details for the last transaction.
You can check these details against the data you stored locally. If they match, all is fine. If they do not match, you will need to investigate the issue.
Never understood why PayPal does not allow the data to be signed with some sort of hash + shared secret... but that does not help you any further.
If you POST the variables to PayPal, you can encrypt the data. Unfortunately, this is not possible for a GET request, triggered from a redirect.
There is a way of getting PayPal to host the button variables on their side. Look out for PayPal Hosted Buttons in their documentation:
https://cms.paypal.com/uk/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_ButtonMgrAPIIntro#id093VD0JE0Y4
Otherwise verify with IPN as mentioned bu Jacco.
Use the PayPal NVP or SOAP API to create an encrypted button. Basically you set all the information using PHP and then the API gives you the HTML.
Alternatively if you only have a couple of products you can make custom buttons.
The API's are well documented and easy to use. Personally I used the NVP as it was recommended for less experienced programmers. You can also use both in with the IPN (Instant Payment Notification) system so that for example digital products can be automatically emailed.
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.