RideBank – cloud-based ticketing questions answered
RideBank™ is a subscription based, digital ticketing service, natively built into the cloud.
RideBank™ gives cities with an existing smartcard infrastructure, the ability to migrate to an account-based solution, in months rather than years, and without upgrading equipment or replacing the existing system.
Security and Privacy
Is your system PCI compliant?
Yes. Snapper only uses payment gateways that are compliant with PCI guidelines.
Our government requires customer data to stay local. Where are your servers?
RideBank™ is developed using native Amazon Web Services (AWS) capability. AWS has regions all over the world, so we can work with the customer to identify the most appropriate AWS region to host their data, so that we can comply with regulatory requirements. https://aws.amazon.com/about-aws/global-infrastructure/
Are you compliant with local regulations including GDPR?
Yes. We have good understanding and experience of GDPR and EU Data Privacy regulations. We are always open to relevant compliance reviews.
How much integration is required with our existing system?
There is no integration required for hardware. Snapper requires
transaction files, which are passed through the RideBank™ fare engine, as well as GTFS feed, Fare Policy, and settlement and apportionment rules for example.
RideBank™ would introduce another interface for administrators to deal with, alongside their other systems. How will they know what to use?
Snapper can provide an API for transaction history and anything related to payment, charges or hot-listing so that this information can be integrated into a single interface for administrators to trouble shoot customer queries.
Our network is offline; can we still use an account-based system?
Yes, for an account-based system operating offline, the frequency of transmission of transaction data to the back-office is what’s important. You manage the risk through the updating of lists in card readers.
If calculations are done post travel, how long do you wait to get a matching transaction?
The time depends on the average frequency of transaction transmission. Snapper can configure rules to suit your network, depending on the distances involved. Automatic and trust-based engines are also used for frequent travellers.
Payments and Risk
What happens if a payment fails?
When a passenger registers for the account-based service they need to provide a payment source such as a bank account or credit card (if it is a post-paid option). Snapper conducts a pre-authorisation of the payment source at that time, which helps to minimise risk from the outset. If there was a failed payment, a rebilling process is used. Rules can be configured for generating a block to a card for a failed payment.
Who will bear the risk of passengers not making their payment?
Snapper bears this risk. Snapper clears and settles all transactions overnight and pays the Transport Authority according to their apportionment rules each day.
Most of our passengers do not have a bank account. If they do have one, it will be a basic salary account without any credit, and often not even a debit card functionality.
For the unbanked, this is an opportunity to use a pre-pay option, where they continue to top up their account via a retailer. There are also other payment sources that can be used such as a mobile wallet; it doesn’t have to be a bank account or a credit card.
Are you able to support concessions?
Yes, RideBank™ supports all concessions.
How confident are you that you can scale from a small city to a large city with millions of customers?
Snapper uses AWS which can scale up and down efficiently as demand changes. Snapper is very confident of this solution as they have been using it successfully in other projects with larger scale cities.
Maybe we can develop this in-house. How long has this taken you to develop?
Snapper has had over 10 years of deep technical experience specific to public transport, including six years of front-end mobile app development.
The Snapper development team has used this experience over the last three years to develop this multi-tenanted account-based solution.
How long will it take to implement RideBank™ with our existing system?
Snapper estimates six months to trial, and an additional three months to full production. A lot of this time is dependent on internal testing requirements and the speed of delivery of the external payment gateway.
We don’t want to be locked in to a new vendor, as our system will be end-of-life in five years and we may choose to replace it. How long is the RideBank™ contract?
Snapper requires a minimum term of three years for the RideBank™ service. As it works alongside your existing system without deep technical integration, it is ideal for a transition to a new system in the future.