I am developing a project in cakephp. And the requirement is to integrate all types of payment getway for donet. I dont know how to integrate credit card like master card, visa, american express etc. into my project in cakephp format.
Please help me. I am very grateful to you.
CakePHP is a programming framework not a banking service.
If you need to do financial transactions, you will need to contact service providers that do this. Major banks mostly provide credit card transactions as a service. They have their own APIs and workflows, mostly something RESTlike.
See for yourself on PayPal for example:
https://merchant.paypal.com/cgi-bin/marketingweb?cmd=_render-content&content_ID=merchant/home
https://www.paypal.com/hu/cgi-bin/webscr?cmd=_merchant-outside
Cake will be a good friend implementing it, though.
Depending on which country you are conducting business in, there may be regulations to adhere to. These usually revolve around confidentiality and security, i.e. card data.
It is far easier to use third party gateways or the APIs provided by banks through their merchant accounts as you transfer the responsibility for that data to them. PayPal is the obvious one - and there are other similar payment mechanisms, but it isn't an ideal solution in every situation.
If transactions need to go straight into a business account, discuss it with your bank. Most banks have their own or a franchised solution.
We build shops with ZenCart and use SagePay as a payment solution, but I doubt it would be available outside of the UK.
Money being money, it makes money every time it is moved and a lot of people want a piece of that. As a result there are a plethora of options to choose from.
If it was a personal / non-business site, I'd use PayPal for ease. What I wouldn't do is try to build my own gateway.
Don't forget, Cake is just PHP and as such is as easy to deal with as any other PHP website. Choose your gateway provider, study its API and everything will become clear.
Related
I'm working for a startup and we have a customer who uses Demandware for their online store.
Our company provides vouchers which are worth a specific amount of money. So customers on the retail site can enter the voucher number near the end of the checkout experience and if it's worth, say, 10 dollars, their shopping cart is updated (-10).
I have the CTO saying we just need to "drop a few lines of javascript" onto the retailer online store. But I think this requires a Demandware plugin (especially updating a shopping cart), which involves signing up for a developer or partnership account (which takes some time), learning Demand Script and building the plugin, then releasing it to Saleforce's app store. Am I correct? Is this the only way to achieve this?
Just to be clear, the functionality is: the voucher code box needs to take a voucher number, an API request is made to our service to check what it's worth, then update the cart.
That's a pretty broad question but I'll try to explain.
First off, Demandware has gone all JavaScript.
But yeah, it has a huge API so the process sounds about right the way you've described it.
Ask your client whether they have a service integrator they're working with, because that would be their job. Your job would be to provide an API so that Demandware can check whether the voucher code is valid.
Demandware is a closed community so it's unlikely to learn it unless you're working in a company that is doing Demandware development.
Oh, and if it somehow ends up being your job to develop this, a tip from me - you probably need to get access to their site's files and use the LineItemCtnr class to createPriceAdjustment() :)
The first tip from me is that Demandware got bought by Salesforce and is now branded as Salesforce Commerce Cloud, so if you hear either, they are the same thing.
You are right that you are going to have to work with Salesforce to get going. They are a cloud provider and there is no self-hosted version of the platform, so in order to do any development, you need to have a relationship with them.
So then it depends on how you get access. If the client has any sandbox environments they are willing to share with you, you could do this as a custom build working in their environment, modifying cart code to make the service call as you ask and as the previous response suggests. But then (depending on the terms you have with the client) your company may or may not be able to reuse that code for other clients. You will also have to work with them to get that integrated into their existing site, get it deployed through their processes, etc.
If you want to write something that other Commerce Cloud clients could use, then you should set up your own partner relationship with Salesforce and get a software package they call a cartridge to what they call their LINK marketplace, which is basically a big clearinghouse of integrations like yours.
Technology-wise, the platform has gone through some changes recently, going from an XML-based GUI tool to specify business logic to using CommonJS scripts to define them. If your client is a new client within the last year or two they probably have this new fully javascript implementation, but if they are an older client than that they may be using the old way, which has a steeper (read: more proprietary) learning curve.
Ok, so about a year ago I wrote a web app that helps organize appointments for my dads company. He now "couldn't do business without it". I have decided that I want to build a SAAS subscription model out of it and open it up to the public.
It's currently built on codeigniter and php which I do not think is a good fit for a SAAS version. I am planning on rebuiling it from scratch in laravel 4 and using stripe as a payment gateway.
My concern is how best to handle the database / application structure for more than one client. Currently, it just serves the one business and is very un-abstract and is specific to my dads companies needs. I need it to be able to handle different data depending on what the business who uses it does.
I have looked into multi-tenancy but i'm not sure this is right for this. I am thinking that a 'gmail' style approach would be better. One app / domain that after login the user will see their customised dashboard and only their data.
Before I get stuck in with the coding I need to work out how best to handle multiple 'accounts' on the one database. I do not want to create a table for each user, nor a database for each user.
I guess my question is can anybody point me in the right direction for how best to handle a monthly payment subscription in Laravel? It's not so much the code that I'm stuggling with, rather what exactly I would need to build to handle charging the customer each month and denying them access if billing failed etc.
Thanks
You are in for a lot of reading and a ton of work!
First of all, let's completely ignore the billing aspect of this for now — at the end of the day that portion of the application is really fairly trivial. Take a page out of 37signals Rework (page 93 and 94) and launch your product with a 30 day free trial before you even begin implementing it (you should know how to implement it by then).
Second, why do you think that "gmail" doesn't use multi-tenancy, URI structure tells nothing about the underlying database structure. I'm fairly confident they aren't cloning a database schema for every one of their customers. Therefore you've probably answered your own question — you want to implement multi-tenancy.
You're going to want to abstract your database (and application architecture), and honestly there is no better resource to help you on your way to doing that than Taylor Otwell's (creator of Laravel) book Laravel: From Apprentice To Artisan. His book is not for beginners, and by the time you're done reading it you should probably be able to answer this question for yourself.
You are not going to be creating a table or a database for each user, you aren't even going to be creating one for each organization. Instead you'll be creating abstract database structure in code, which will pull your users data out of the database.
Think about checking for permission to access an organization as another layer of user authentication. On every request you'll be checking to see if that user can access a particular organization. You'll likely also check to ensure that organization is still active (did it expire because they didn't pay?) this will again happen on every request and likely with a filter within laravel.
This really leads to the next very important factor of developing a SaaS application.
I don't know about you, but I'm paranoid, and I couldn't sleep well at night if I wasn't sure that user number 4506 couldn't see the data of an organization that he doesn't belong to. The only really good way to ensure this is through unit testing, which I'd highly suggest learning if you haven't already.
The best way to do this within Laravel 4 is to read Jeffrey Way's book Laravel Testing Decoded. This book is extremely advanced, but still easy to understand if you have a good grasp of the fundamentals.
Last but not least, the number one thing is get involved in the community — the easiest way I'd suggest doing that is idling on the #laravel IRC channel (freenode). Ask some questions, maybe answer some questions, everyone in the channel is very nice and responsive.
You are definitely in for an adventure, don't be afraid to ask questions and make mistakes. Good luck.
As a rough overview, I would have a clients table, and a subscriptions table. Any other data that needs storing such as contacts, or appointments, can be associated using foreign keys to the client table.
In laravel, you can use the ORM to get the currently logged in client, and then through a relationship, fetch appointments and contacts belonging to them.
There are some useful tools for laravel at cartalyst.com, including sentry and sentry-social for user auth, and integrating user accounts with facebook/google/twitter, etc.
Stripe will allow you to configure recurring payments, and will notify you via web hooks each time there is a payment attempt. you can log these in the payments table, and associate them with a user/client. you can use this to keep track of who has paid, and how recently.
Also, bear in mind that you may not want to cancel the account immediately on failed payment.
Stripe will reattempt, and it may be that your best response is after it is two or three days late, or you get an invalid card notification,to get in touch with the client and prompt them to update their payment details.
It may also be an opportunity to check when they last logged in.
If it was over a month ago you can credit them with a free month, and remind them of how much your app can do for them.
By doing this, you may be able to get people to continue using (and paying) for something they had forgotten they had subscribed to.
I am looking for a method of dynamically linking product information based on the name of the product.
For example: User types in "Playstation 3", the site would then go out and grab any information it can, such as picture, retail price, etc. Ideally, it would let you choose the correct item (returns both ps3 controller and ps3 console, user can choose which). It would then use this information in a product listing.
The easiest way I can think to implement this is to use the existing API of a major retailer such as Amazon. I have a couple completely different ideas for sites, one of which would involve selling from amazon (which I would assume they would be ok with) and another which would only be data mining the information. I am concerned they would not take it very kindly if I was just stealing their images and descriptions.
Is there another way, maybe less "sneaky" way to accomplish this that wouldn't be in legally frowned upon ?
Many web-commerce companies use a data stream known as an API - EBay, Etsy, and Amazon all have API feeds for their products. If you can convince the company to allow you access to their API (usually they will give you a key/password), then you can directly access their back-end database, typically at the read-only level. Depending on the company, you can just write them directly for access.
You are correct when you say that most companies wouldn't take kindly to someone web-scraping their product directory and re-using it. That is unethical, and could lead to big trouble with larger companies with a significant legal presence.
On the other hand, there is nothing to prevent you from cobbling together several API feeds into a Mash-Up - try Yahoo Pipes! to learn the basics of API/Mash-Up integration:
Yahoo Pipes:
http://pipes.yahoo.com/pipes/
Here is the link to Amazon's Product Advertising API program:
https://affiliate-program.amazon.com/gp/advertising/api/detail/main.html
Good luck, and happy development!
Many online retailers provide a product feed - either well-publicized (William M-B has listed some examples), or sorta-kinda hidden, for the purposes of affiliate marketing. They usually have terms of use around those product feeds, describing in detail what you're allowed to do with them, and exactly how many of your limbs are at risk if you don't play by their rules.
However, the mechanism you're describing sounds remarkably similar to a search engine; there's a well-established precedent for search engines indexing sites, and using their content to reason about the underlying site. Get a lawyer to validate this, but there's a good chance that your intended purpose falls under "fair use".
I'm representative of http://aerse.com.
We are building service, that do the following:
search product by name. For example: galaxy s3, galaxy s 3 or galaxy sIII
return technical specifications (CPU, RAM etc) and product images (thumbnails and high-res images)
provide API http://aerse.com/p
deal with legal issues, provide licenses & etc.
Does anyone know of any documentation of how to access bank data via some sort of webservice or other method for use in a Silverlight financial / banking application? Is there any sort of standard protocol or terminology used for this that I can look up online. I'm having trouble finding any sort of information on how this is typically done.
"Access bank data"... Not exactly something banks allow from the outside world. They kinda want to keep things secure :)
If you work for a bank you may well have access to various web services internally. There are standards for data transfers, but every bank will likely have it's own systems.
I'm having trouble finding any sort of information on how this is typically done.
That's probably a good thing. This is typically done by either internal bank developers or consultants. For example, take the Bank of America Windows Phone 7 app (which is a Silverlight app): it connects to BofA's servers, but I would be surprised if the way in which it connects is public information. Because you can use it to check your account, I can only presume that there is a web service hosted somewhere that allows these clients to get this data. I'm pretty confident, however, that the connection is secured, and the details of it are kept hidden for good reason.
In short, banks don't usually expose web services to the outside world for public consumption. Unless you've been hired by a bank to specifically do this, I'm not sure you should be able to.
I have been trying to understand how this problem is solved for over a month now. I really need to come up with a general approach that work. I have a theory, but I'm just not sure it's the easiest (or correct) approach and I haven't been able to find any information to support my ideas.
Here's the scenario:
1) You have a complex web application that offers secure content on a subscription basis.
2) Users are required to log in to your application with user name and password.
3) You sell to large corporations, which already have a corporate authentication technology (for example, Active Directory).
4) You would like to integrate with the corporate authentication mechanism to allow their users to log onto your Web App without having to enter their user name and password.
Now, any solution you come up with will have to provide a mechanism for:
adding new users
removing users
changing user information
allowing users to log in
Ideally, all these would happen "automagically" when the corporate customer made the corresponding changes to their own authentication.
Now, I have a theory that the way to do this (at least for Active Directory) would be for me to write a client-side app that integrates with the customer's Active Directory to track the targeted changes, and then communicate those changes to my Web App. I think that if this communication were done via Web Services offered by my web app, then it would maintain an unhackable level of security, which would obviously be a requirement for these corporate customers.
I've found some information about a Microsoft product called Active Directory Federation Service (ADFS) which may or may not be the right approach for me. It seems to be a bit bulky and have some requirements that might not work for all customers.
For other existing ID scenarios (like Athens and Shibboleth), I don't think a client application is necessary. It's probably just a matter of tying into the existing ID services.
I would appreciate any advice anyone has on anything I've mentioned here. In particular, if you can tell me if my theory is correct about providing a client-side app that communicates with server-side Web Services, or if I'm totally going in the wrong direction. Also, if you could point me at any web sites or articles that explain how to do this, I'd really appreciate it. My research has not turned up much so far.
Finally, if you could let me know of any Web applications that currently offer this service (particularly as tied to a corporate Active Directory), I would be very grateful. I am wondering if other B2B Web app's like salesforce.com, or hoovers.com offer a similar service for their corporate customers.
I hate being in the dark and would greatly appreciate any light you can shed ...
Jeremy
Shibboleth is designed to support exactly this scenario. However it will rely on your customers' companies implementing the identity provider mechanisms. At the moment, that's only really common in universities. Further, if you want user information (any more than just a pseudonymous identifier), you'd need the company to agree to release those attributes to you.
I find it hard to believe that many companies would open their corporate authentication system to you, just to provide SSO.
You might find it better to rely on OpenID or similar, and using a "remember me" cookie to reduce the need for people to enter passwords.
One basic problem with your approach is that you're considering your web app in isolation. Employees at your client's company won't just require SSO to your web app but also some/few/many others, and extending your approach would require a bespoke implementation for each of those to enable access.
Hence the widespread adoption of OpenAthens and Shibboleth in the academic library community to leverage the use of locally-issued credentials. A typical medium/large university can subscribe to various products/services from more than fifty different publishers, and by deploying OpenAthens/Shibboleth they can take advantage of the SAML open standard (SAML is the protocol that Shibboleth uses) that is seeing increased take-up not only in the academic sector, but also in the commercial sector.
John's answer above points to another issue: there are a number of open standards that have recently emerged, SAML and OpenID among them. So content providers are having to decide whether they want to implement some or all of these natively, but they use separate technology stacks and so the implementation and support costs can be duplicated.
Quite a few major publishers have implemented OpenAthens as this supports Athens, SAML/Shibboleth and OpenID in a single platform, with options to plug in other technologies too, or writing a custom module to allow an internal app to connect, e.g. an invoicing or entitlements system recording which clients' users are logging in.
This sector of access management is definitely moving towards open standards, so building your own method would be depriving access to your app for a large number of users