Forum Moderators: buckworks
I know PHP programming well, but i have never written such an application. So my question is to ask if there is a premade application that I can download and use it (How much does it cost?)
Another question, may I ask what goes on behind the scene once the credit card number has been provided by the client?
Plaese, give me how the system works
I know PHP programming well, but i have never written such an application.
First stop: How does your client plan to accept money?
Some common responses:
- "Send me the credit card info via email, I already have a terminal and will run it manually."
Bad, bad, bad. For one, most offline merchant account contracts specifically state the use of the account is for card present or phone orders only, and using the account to process orders collected over the Internet can make the account holder liable for fines and charges in arrears for the period in which they collected these transactions. Online merchant accounts have a different pricing structure including the per-transaction charge.
Second, accepting CC info via email or even storing it on your server makes the account holder liable in the event of security breaches. Read up on PCI compliance [pcicomplianceguide.org] as suggested by the previous post, make your client aware of the liabilities.
- "Via payPal".
Easy enough, there are a variety of methods to accept payments via payPal from in-page "checkout" buttons to slick silent post methods so the visitor never leaves the site.
- "Okay, so if I can't accept CC info via email, and refuse to use payPal, how does everyone else do it?"
Most online merchants have either two merchant accounts - one for offline terminals, and one for online transactions - or a merchant account that accommodates both, or just an online merchant account. Notable to mention, most online merchant accounts can be used as a "virtual terminal" to eliminate the offline terminal. Your client will have to get an online merchant account, or request a change in their current merchant account to accommodate online transactions.
The merchant account is not a "direct" connection in many cases and requires a gateway that you actually connect to, and the gateway queries your merchant account for the charges. For example, the merchant account is with "National Bank" and requires the Authorize.net gateway to accept the transactions (most banks/financial institutions will tell you what gateways they support.) This means charges from the bank for the merchant account and per-transaction charges, and charges for the gateway account.
Some banks, such as FirstData, host their own gateway (LinkPoint) so these are combined into a single charge.
In any of the acceptable cases - payPal, online merchant account - you will find documentation in payPal or in the gateway account to integrate your site to their API. These can be direct "in-page" transactions, where on checkout the visitor actually navigates to the secure gateway, or via "silent post" so that you post the info to the gateway using curl or some other method, returning a response to the site. The impression is that the visitor never leaves your site. In this second case, a valid SSL cert is required.
In the documentation, you will find code samples as the basic framework for integrating a site to their system in most languages - I've seen PHP samples in all of the ones I've worked with.
So the second stop - after convincing them the first option is a very bad idea, which you surely should - is to acquire the login to their gateway account for the purpose of gathering the documentation and samples, putting the account in global test mode, and implementing the tests and final live connection. Many gateways only have the documentation available after logging in to the account.
