Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm looking for recommendations for vendors - quite possibly start-ups - who can help with two challenging requirements for an app I'm building right now. We're really open to new and innovative solutions to these two challenges. I've got a lot of control in terms of dictating choice of browser, selection of hardware, and even choice of operating system (I could probably, for example, require the use of Macs).
Any recommendations, links, or insights would be really appreciated. I've spent some time poking around online, but there's a ton of companies offering the same old crap that would probably be hell to integrate with a modern web app.
So here's the situation. My client is a successful, long-standing consultancy in the fitness industry. In 2006 we developed a web application for managing the personal training departments of fitness clubs. This system is in use in approximately 20 organizations in Canada and the US, some of which are quite large. There are currently 1100 users of the system, which tracks over 50,000 clients and some 80,000 transactions totaling $25 million in sales for these clubs. The business model is Software-as-a-Service in conjunction with ongoing consulting and training, primarily to improve operations, sales, and human resource management.
We are currently developing a new and significantly expanded platform, using Ruby on Rails as our web application platform. We believe this application has the potential to acquire many new clients who are frustrated with current software solutions for the fitness industry, which tend to be bloated, complicated and hard-to-use.
One important thing to note about this system is that it handles multiple clubs, which are separate businesses in their own right, with their own clients, bank accounts, etc.
We're currently faced with two challenging requirements for the system.
Access Control
Clubs need to control access to their club. Some do this by keeping staff at a front-desk, others do this with a completely automated system. When clients walk in the front door, they need to swipe a card, enter a code, or use a biometric system (our preference is for the latter; the trend seems to be to use hand scanners that accept a code but also require hand placement on a pad for entry). The system needs to send this information to the web application, which will return a success/failure response in the case of a fully automated system, or display the client profile to front desk staff.
Requirements for working in a club:
physical scan to gain entry: card swipe or preferably, something biometric like a hand scanner. * can process many thousands of clients. * can prevent clients from entrance if they fail to be recognized, or if a failure code (e.g. membership expiry) is returned when the scan is performed.
Requirements for integration with web application:
sends identification information to computer in a way that can be read by a web application. Process: device scans the client, sends client's ID number to the web application, web application responds with yes/no for entry, and displays client information to front-desk staff. One possibility would be the availability of software, presumably provided by the manufacturer of the device, that would transmit the information read by the device into a web form, i.e. it would work like a keyboard wedge. We are open to recommendations.
When a client account is created, a unique identifier will be created by the web application. The device must provide some method of storing this unique identifier, either in the card itself in a card reader, or via some other method in other (e.g. biometric situations). In other words, the device must provide an interface that allows for the web application to set up new clients in conjunction with the device and the access control system.
Payment Processing
The application must be able to process credit- and debit-card payments. Most of these will be card-present transactions, both credit- and debit-card based. Customers of the fitness clubs (who are the customers of my client) that use the application will often be present to swipe their cards for their payments to be processed, which requires integration with PIN pads. Some of these will be one-time transactions, others will be recurring.
The application deals with separate businesses that all have their own bank accounts. The money from transactions processed by the app has to be deposited into the bank accounts that belong to individual businesses. I believe this means that PCI requirements are substantially more onerous for an app like this because my client is classed as a payment service provider, rather than just a user. My conversations with payment providers have indicated that the cost of this type of certification is much too high for my client to afford (something in the range of $100k, for hiring an independent security assessor and working with them to achieve compliance).
Additionally, if possible, the application should also support electronic funds transfer.
So far I think my preference is for partnership with a vendor who is already PCI-certified and has the PIN pads for card-present transactions, whose software has a good API that I can interact with via this web application.
I've got lots of experience with traditional e-commerce models in Rails, and I'm comfortable with the technical aspects of dealing with multiple bank accounts, but the certification requirements appear to be the major obstacle so far.
I think you've answered you own question with the payment processing. You need to partner with a vendor that is already PCI-certified. The fact that your clients will have recurring payments means you have to keep their customers' credit card numbers in a system, which requires PCI certification.
Regarding the access control, again a vendor should be able to help. I don't think you should look to send the challenge/request over the web. You'll need a local, low-cost PC to connect to the biometric or card reader.
I think you should maintain a local database of authenticated customers on the PC that handles access control. This is recommended because if the location's Internet connection goes down, customers still get in for their workouts. Use a batch system to keep the database updated.
Update: On further thought- the fitness centers will have a desk with a few computers used by employees. Set up a little web app on the controller PC to handle access. Train employees to go to the "Access Control Site" to manage access. You might even be able to embed an IFrame in your web app and point it to the local access manager to make it look like an integrated part of your SaaS offering.
Related
Does anyone know where can I find any kind of technical documentation on Electronic Cash Register interface (ECRi).
It's supposed to be a standard for semi-integrated scenarios, where external application (POS) communicates with a credit card terminal using relatively simple commands (like start sale for $100), without having access to any sensitive credit card details (thus no need for PCI certification).
VeriFone Vx820 Duet is one of the terminals that implements this standard.
I assume communication is performed over TCP/IP, but I can't find anything more.
Is this really a standard, or just a common name for this kind of integration?
Are terminal vendors responsible for this kind of API -or- rather it is some application, that exposes this functionality, and is uploaded to the terminal by specific merchant/bank?
There are a lot of standards for ECR-EFT integrations, but there is no single protocol guaranteed to be implemented on both POS terminal and ECR side.
Generally, recognized standards are:
Polish FROB protocol - the one you're probably asking about is the new polish standard by Fundacja Rozwoju Obrotu Bezgotówkowego, which is supposed to become a part of ECR fiscal certification. You can register for free at the website and access the repository w/ code snippets, simulators and specifications. Kindly note, that the work on specs is still in progress so it may be subject to change. There were also minor bugs in simulators implementation at the time we were working on our own integration project, maybe something has changed since then.
Nexo - European approach to ECR-EFT unification
OPI - Open Payment Initiative
ZVT - German standard, far exceeding scope of current integrations
on the polish market there are a lot of semi-semi-standards, as a lot of ECR manufacturers implement each others proprietary protocols. There are options to implement only a few of them to gain a significant market coverage, but for that you'll have to do your own research and check with customer needs.
Let me know, if you have questions regarding specific markets or usages
if i want to put an framework library to sale then how can i put license to it so that it cannot be transferable for iOS/iPhone.
I got few ideas:
I can implement an web service then i thought that can be access in offline.
It can be given for limited persons but if the app went on the live how can we handle.
any info will be helpful.
Regards.
For purposes of this answer, I'll skip over the parts about how to make a framework. There are many posts out there to explain that part.
The business logic of licensing a framework is much more difficult than the actual implementation. You should answer a few questions for yourself first:
What is the license model? Per User? Per Application? Per Developer?
Who am I targeting with this framework?
Is my license limit a hard limit (App stops working if exceeded) or a soft limit (App keeps working, but I find out so I can charge more money)?
How much money am I willing to spend to enforce honesty? How much extra money do I need to make to justify my expenses to enforce this?
If you can build your license model per application, you will have the easiest time enforcing your license. Each app can require an unlock code, which is specific to the app bundle name. If the bundle name doesn't match, the key doesn't work, and your license is enforced.
Licensing per developer is a bit tricker. Generally, you'll have to rely upon the honesty of the people purchasing your app. I'm not aware of any good mechanisms for enforcing per developer licenses.
Licensing per user, as your question seemed to be targeted, has a much broader range of mechanisms that you can utilize. The most basic is to enforce the parameters within your contract. Most contracts have monthly or quarterly reporting standards. This places the burden upon your client to keep you up to date when they add new clients. If you target your framework for professional developers, this is probably an accurate enough mechanism.
If you are targeting entry-level developers, that will very likely drop off the map, you have to use stricter mechanisms if you want to enforce your license. They will all require a web service to manage your licenses.
Your code will need to reach back to a web service and provide an installation identifier, such as [UIDevice -identifierForVendor], as well as the Bundle Identifier. This will give you an accurate count of how many installations of your library are out there and who is using the.
At this point, you have a decision to make about how to enforce your license. If you have a hard limit on users, which I do NOT suggest, you can refuse to unlock your library if the licensed number of users for the app bundle has been exceeded. If you have a soft limit, which I also do NOT suggest, you allow everyone to always unlock and then go after the app vender for exceeding their licensed user count, or potentially not having a license at all.
What is generally an appropriate method is to use a combination of hard and soft limits. The app must report to the web service at least once every 14 days, which allows for offline use. If the library has not reported in within that window, it stops working. The web service makes a decision about whether to unlock the library based solely off the app Bundle Identifier. If the license for a specific bundle exceeds the number of seats, you notify them and give them a window (maybe 90 days) to purchase more licenses. If they decline, you block that Bundle Identifier. Then your customer can either remove your framework from their bundle or negotiate a new license.
The down side to all this all cost money and development time. In most cases, the money you could earn by licensing your code exceeds the amount of work it would take to build and maintain such a system. The maintenance and upkeep cost for the backend are nearly the same if you have 1 user or 1,000,000 users. Be sure you have enough users to justify the effort and expense before going down this path.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm creating an iOS app that uses remote databases, sessions (login/registration), server side code, and push notifications.
I found this SDK called Parse that handles all of the server stuff like hosting, the database, cloud code, push notifications, sessions, etc... (so pretty much everything I need to do)
Is Parse SDK worth using (cost-wise) in general?
NOTE - FTR, PARSE HAVE TOTALLY CHANGED THEIR PRICING PLANS (5/2014)
these are the old plans...
With the free version, you get 1 million requests a month (I'm guessing this means requests to the database?), 1 million pushes a month, and the burst limit is 20/second.
The next version up costs $199/month, you get 15 million requests a month, 5 million pushes, and the burst limit is 40/second.
Do you think it will pay for itself if goes over 1 million requests / month, and I have to pay for the $199/month version? What if I plan on making money with my app via ads, will it earn enough?
Let's say every person accesses the database 5 times a day, that's 150 times a month, that means it will take 6,666 people until I have to upgrade. On average, will ads pay for the $199/month if I have that many people viewing the ads a day? (also, take into account that Parse is taking care of security, the cost of the servers, and maintenance)
Another thing to consider is, how difficult/costly is it to create (and maintain):
Server side code
Database management and security
Push notifications
Set up a host
Session management and security
Will the robustness, security, and ease of maintainability when using Parse will help pay for itself?
Thanks!
As someone who has looked into this before, to see if its "worth it" it depends on a few things. And i have a few questions followed by some answers if these are your cases.
Does your app cost?
If not then look at how you are going to make the money, will you cover the expenses? I Imagine even with advertising only on a free app you will be making enough money to cover the expenses. If you start to have "too many" requests.. that's a GOOD thing! it means you have a lot of users or active users which in an advertising sense, is good. Or even in a paid app sense.
Does your app have a bunch of requests operations?
For example, in my app we have a chat system, obviously that's going to be a heavy load on requests. Take that into consideration
Are you in a hurry to develop?
If your in a hurry, obviously go with Parse, they handle a lot of great things for you and is a really amazing product. fast secure and reliable.
So if you're in a hurry, and are expecting users. Then go for it! Even if you don't get users, you can always go with Parse Free and when you reach your limits with Parse Free, you should have enough users to start paying and upgrading your services.
Also, paying for server maintenance is no joke. The only reason we do not use parse, is because of the fact that we like to have control. And even Parse is giving you more and more control each release.
Once Push Notifications have been implemented and are being used, there's really no maintenance after that.
In a nutshell, yes. Parse allows developers with little to no infrastructure to execute on an idea without the need to pre-purchase hardware in anticipation of traffic or scale overnight if an idea goes viral.
Another way to look at it is - Would you rather focus on the app/idea or the backend infrastructure along with maintenance? Personally I almost consider the $199 the cost of doing business so to speak and allowing me to focus on implementing new features.
Ads and donations will help make a dent but it's the ease of upgrade where they are most beneficial. Updating your own personal hosting can be anything but easy if your app gains critical mass overnight.
PS - Check out their docs for some quick ways to implement things such as log in pages: Parse Login and Signup Views
Reference: I've used Parse with some indie projects and in an enterprise setting.
From some reading and input from a couple of seasoned developers, it appears that I'm down to a choice between Recurly and RailsKits.com SaaS Kit. I'm hopeful to get some broader experiences from folks in the community here as to the pros and cons perhaps you've experienced.
I'd really like to be sure that I put together an apples-to-apples comparison here.
First, I'm offering a service that has two subscription levels of about $1 and $5 / month recurring. These may be paid in either monthly, yearly or every three years (get some discounts at the longer subscription levels). I obviously need to keep transactional costs as low as possible, but I need to maintain this and be sure that recurring billing is reliable and not problematic.
I'll be building this atop Rails 3.
The bag seems mixed as you get a more robust admin feature set it seems with Recurly, yet I may be able to save enough with a SaaS Kit + (for example) https://merchant-apply.com/tesly to make it worth it.
I have reviewed Chargify vs Recurly and Recurly seems to be the winner for my particular model and so that's why I've kinda eliminated many other options at this point.
If you've faced this before, what has worked for you or do you have some practical input in this regard?
I work at Recurly, so I'll try to not make this a sales pitch :)
As I noted in the comments above, PCI compliance can be tricky, time-consuming, and expensive, so please check each product and see what is required for your business. You can see documentation on Recurly's PCI compliance requirements at http://docs.recurly.com/security/pci-compliance/. SaaS Kit reduces some elements of PCI compliance by storing the payment information with the gateway, but this means you cannot easily switch payment gateways - most gateways will not allow you to take your data with you. If you choose to use Authorize.net's CIM service with SaaS Kit, this will be an additional $20/month gateway fee for the credit card storage.
I also recommend you take a look at the API docs of each product. Depending on your integration complexity with Recurly, some merchants never need to work with the API (instead using hosted checkout pages and the admin virtual console inside Recurly), but other merchants will have a more complex billing scenario that involves use of the API. The docs for each product should give you a good idea of how easy they will be to work with.
I'd be happy to answer any questions you have as you continue to look!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We have the following systems (and more) that we push/pull data from one app to another:
Hosted CRM (InsideSales.com)
Asterisk phone system (internal)
Banner ad system (openx, we host)
A lead generation system (homegrown)
Ecommerce store (spree, we host)
A job board (homegrown)
A number of job site scrapes + inbound job feeds
An email delivery system (like Mailchimp, homegrown)
An event management system (like eventbrite, homegrown)
A dashboard system (lots of charts and reports pulling info from all other systems)
With Rails 3 around the corner, I really want to pursue a micro-app strategy, but I'm trying to decide if I should have the apps talk via REST HTTP API or because I control them all, should I do something like shared models in the code which simplifies but also allows for stuff to leak across boundries much easier...
I've heard 37signals has lots of small apps, I'm curious how those apps communicate with each other... Or if you have any advice from your own multi-app experience.
Thanks! I tried asking this on my blog http://rywalker.com/chaos-2010 too a while back.
I actually got an email response from DHH...
We use a combination of both, but we default to REST integration. The only place where we use direct database integration is with 37signals ID user database. Because it needs to be so fast. REST is much more sane. Start there, then optimize later if need be.
Last time I had to crazy-glue a bunch of small applications together, I used a simple REST API.
Bonus points: it allows for integration with services / apps written in other languages.
Also helps if you've got a crazy buzz-word loving manager who likes to pivot technologies without warning.
i had the same with a plus: I had to talk as well with some daemons that were not exactly HTTP ready. So i followed the following pattern:
REST API using XML/JSON to exchange data and using memcache to exchange short messages. (you define some keys that you will update in memcache and the other piece of software, just pull memcache looking for those keys)
as security measure i added API KEY or HTTP client authentication using digital certificate.
Another option is AMQP messaging (via rabbitmq or other means).