I have gone through the document given by the site and I also have code snippets but I am confused about the Salem and PNS.
PNS stands for Payment Network Services, a generic term for all of their merchant payment offerings, and Salem is the Stratus platform originally located in Salem, Massachusetts.
The Salem platform is optimized for a small number of merchants which have high-volume transactions, such as Amazon, Apple, eBay, and Google. Traditionally, it only had dedicated ATM connections to these "high value" merchants. Nowadays, I believe it is accessible through NetConnect and Orbital.
The other platform is internally referenced as Tampa and is the one which the vast majority of merchants interact with when using the Orbital Gateway. It uses Tandem machines to process higher volumes of merchants submitting relatively small numbers of requests each.
Perhaps thinking of it this way will help. Salem is marketed for companies which have very high volume of transactions (think millions / day), but are few in number. Tampa is marketed for "the rest".
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.
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!
Has anybody been in or has seen a kind of "Surgical Team" as described in The Mythical Man Month? Have you heard of somebody actually implementing "Mill's Proposal"?
There is a lot of detail about the various roles in the book itself, but for those who haven't read the book, I found a website and a blog post which give a good summary. I've quoted the roles from the website below:
The Surgical Team
The surgeon is the chief programmer and the el-presidente of the whole
team. He produces all the
specifications, codes the entire
system the team is responsible for,
tests it, and drafts its supporting
documentation.
The copilot is the surgeon’s assistant. His main purpose is to
share in the thinking about design
issues – to serve as a sounding board,
as it were. The copilot represents the
team in meetings with other teams. He
knows the code intimately, and serves
as insurance in case of disaster to
the surgeon.
The toolsmith supports the surgeon and builds specialized utilities and
tools as may be required by his
surgeon. Each team has its dedicated
toolsmith in addition to any central
services provided by the rest of the
project infrastructure. The tester is
responsible for maintaining test cases
for testing the surgeon’s work as he
writes it. He is both an adversary who
devises test cases to measure against
the formal specs and devises test data
to be used in debugging.
The language lawyer, which can serve several surgeons, I a widely consulted
specialist who delights in the mastery
of the intricacies of the programming
languages and the operating systems
upon which the software must perform.
The administrator handles money, people, space, and machines. The
surgeon is the ultimate boss, with the
last word on all these issues, but the
day to day management of the issues
and interfacing with the
administrative machinery of the
project is the role of a professional
administrator. One administrator may
serve more than one team.
The editor edits and revises the documentation as drafted or dictated
by the surgeon and oversees the
mechanics of its production.
The program clerk, trained as a secretary, is responsible for
maintaining all the machine-readable
and human-readable technical records
generated by the team. All the filing
and indexing is the responsibility of
the program clerk.
The secretaries handle the project correspondence and non-project files.
We did use the surgical team approach of Brooks' at a startup we set up about 10 years ago. We were five people at the company plus a few others at the uni lab supporting us. The experience was technically great, but it didn't last long for business reasons. :-)
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.