When users make credit card transactions on my web app, I'd like to include the transaction fee on the confirmation page before the user makes the order. The thing is, there are different transaction fees for different cards. Is there a way to determine a transaction fee from the card number?
I'm using Rails and ActiveMerchant, but I figure this question was applicable to other languages as well.
Note that the transaction fee that your merchant account provider charges you is almost never a single amount per card type (Visa / MC / Amex). Rather, the amount varies depending on the style of card (Visa regular card vs Visa Corporate cards, vs Visa Signature Reward cards vs International Visa card, etc).
The different rates depend on how highly "qualified" the card is.
And there is no way to tell what kind of card / transaction fee you'll be charged for the card ahead of time. -- The banks don't want you to know the fee ahead of time since that would give merchants a financial incentive to refuse the more expensive types of cards.
I recommend: check your merchant account bank statement. Figure out the average transaction fee that your bank is charging you, then charge that to your customers. It's almost always a combination of a rate and a per transaction amount. Eg 2.2% / $.10
And remember that to get the best qualification, always send the bank the customer's street address and zip, and put values in the order number, description and po fields. If you don't have a po from the customer, make one up from the customer's name and telephone.
I've also heard of some merchants putting a fixed value in the tax field, apparently there are corp cards where you'll get a better qualification if the tax field has a value.
You can use the Bank Card Number as a heuristic for determining the card type before actually submitting the transaction. There is also a much more detailed list, but you probably just need Visa/MC/Discover/AmEx determination I'm guessing.
Related
I'm trying out InfluxDB to know if my usecase fits.
My app generates a bunch of events like product created, product deleted, product purchased, payment recieved, category created etc. Each event has some other properties such as who created the product or what the payment method was...
I want to know how many products were purchased or howmany payments were done using a specific payment method or howmany payments were done for a day or till now or with in a time specified. Same for all the events like payment, shipping etc. I am yet to understand the concept of TSDB. Every example I see has some value that is varying, ie; temperature 23,30,23,35,24,33 and so on. In my app each event has a value of 1, since each event contibute to one unit of that event.
Is InfluxDB a good choice for this usecase ? If yes, How would I model my data for use cases like this ?
You could use TSDB for your e-commerce analysis but it might be better to try data warehouse instead, especially when your data volume grows rapidly.
TSDB are best used with time series data plus time series analysis. For example, if you care when the shopping cart is filled and emptied but don't care that much about what is in the shopping cart.
Your use case is more like OLAP and you could check out ClickHouse.
I'm currently developing an application where I need to implement some sort of way of handling credits which are purchased by users of my application. These credits will then be used to preform certain tasks inside my application such as purchasing hits in mechanical turk. The reason I need to do this is because in the case of mechanical turk there is a possibility that our orders won't be filled and instead of just keeping the extra money for hits they didn't get I want to credit them for future purchases.
The important parts I need help fleshing out is how do you accurately manage an ongoing total of credits. I can't obviously calculate it every time. Additionally I need to manage the adding and subtracting of the credits. Also I probably need to track the origin of these credits, ie money or free because it is possible we might give out free credits as a reward but we need to be careful how to handle turning free credits into cash because it opens an incentive for scammers to use the credits to purchase turk hits then do the turk hit themselves and keep the money.
I currently work on a system with something very similar.
Users have an Account which tracks all transactions - origin, type and amount. We have a finite number of transactions types (including obvious the ones like credit/debit). The Account table is therefore actually an archive of all of the transactions for a particular user account, rather than being a simple running total.
Account totals are therefore calculated every time we need them, although it would be pretty simple to add some aggregates to the database that increment/decrement a total value as transactions are processed. As with all performance-related issues - don't do it until you need to, summing values across some smartly indexed columns is fine for our current system.
General Problem
How do retail establishments constrain activation for gift cards, or those pre-paid phone/debit cards?
They must have a system in place that only keeps you from calling in to activate cards that haven't scanned through the register, and I assume there must be a standard solution built into the retail ERP/accounting systems. It probably involves web services or EDI.
Specific Problem
I ask all this because one of my clients wants me to develop a product that you get into by purchasing a $30 card at a retail store. The card has a unique number on it. Once you've purchased a card and activated it via a web site, coupons for restaurants and so on are emailed to you periodically.
However, if someone were to steal a bunch of cards or figure out the numbering sequence, we don't want the cards to work.
Presumably, this is a solved problem because retailers are doing this with the products above (pre-paid phone cards, etc).
I can think of a number of ways to solve this problem, however I need to provide the "standard" solution that the retailers expect, so that the product will snap into their infrastructure in the normal way.
Thanks a lot!
I've worked on a few of these types of systems and they all basically work the same way. The card has a # encoded into the magnetic strip (it could also be a barcode). That's usually all that's on the card itself. Cards are then activated at time of purchase.
Here's the basic flow:
Customer comes in and purchases a card:
The card is swiped and/or scanned.
A call is made to an on-line system (usually via some type of webservice call). It includes the card #, the amount they are activating with, and maybe a bit of additional information (ex. invoice #), and possible something like the previous transaction #.
If the call is successful, you get back a transaction ID #.
If the call fails, there is usually some protocol you are supposed to follow (sometimes handled during the daily settlement process). Things like retrying the activation, or running a query to determine if the last transaction went through.
If it was successful, the card is now active.
So basically, the card is worthless until it's activated. At that point it becomes "live" and has money associated with it. That is, back on some server somewhere is a database that has this card #, when/where it was activated, amounts, etc.
There is usually some functionality to generate an "end of day" transaction report to help you reconcile your numbers (what your system says vs what they have recorded).
Since cards are centrally managed it becomes easy for them to flag cards if they were stolen (not that it matters since they have $0 value until they have been activated).
I found out through other sources that there are about eight card processing services that integrate with the various retail locations.
Each retail location uses one. When a card scans through the register, the retailer notifies the card processing service (unlocking the PIN so that it can be activated), and then presumably the card processing service notifies us via an API call.
Then, when the customer goes to activate their card, we can tell which ones have scanned through the register (because they are unlocked). In this way, we get around problems surrounding stolen cards or guessed pin numbers.
The names of a few of these networks are:
Blackhawk Networks
InCom
Coin Star
I had the joy of working on one of these systems right out of college. Depending on the way they handle their processing whether end of day batch or weekly report could cause quite a lot of problems. One of the things I saw was that if the person whom had the card, whether legit or not, if they managed to make a bunch of purchases that were < the day's starting balance but by the end of the day > greater than starting balance all the purchases would go through. Not very fun when the company had to swallow upwards of 100 dollars per user a day.
In terms of security, make the company that you interface with be held responsible for purchases. That is the best way of handling this in what I have seen, because that is what they are there for. Hope that helps in some roundabout way.
You have to be careful, I have seen this played out in retailers..a customer in front of you is asked if they have a loyalty card by the cashier. The customer says no, but the customer behind them offers their card and it gets swiped hence collecting points for something that they did not buy...
Thus gets points at the expense of the customer in not having it thus skewing/distorting the results of the customer (the one who has a loyalty card)'s personal shopping experience and what they did not buy...on the appropriate system's database
In short, there is no foolproof way of getting around that other than asking for a retina scan or finger print that identifies the customer. Some customers would be cautious in joining a club in regards to their privacy...that is another thing to be kept in mind...not all of them would have a loyalty card...
Hope this helps,
Best regards,
Tom.
I believe that the most secure solution possible is to have a server that generates and prints (or exports) the card numbers. When a customer is interested in purchasing a gift card, it is scanned at the register and the register notifies the server that the card has been approved (probably with the credentials of the cashier).
Then when input on your website, the website checks with the card server to see if the card number is valid and approved.
Then, stolen cards are not approved. If someone figures out the numbering scheme, then you may be screwed so it is recommended that the numbers be random with enough digits to make guessing numbers unreasonable (perhaps with something similar to a CV2 code).
This is similar to how debit cards work: card number/CV2 generated ("server") -> shipped to customer -> customer activates via phone ("register", with the "credentials" being their SSN or similar) -> customer then uses at a store and the store contacts the card company's server
I know that Intuit Quickbooks Point of Sale offers a service like this (complete with an API), you could look them up.
I like HalfBrain's solution. I'd also imagine they have certain pieces of security in mind, like a single IP address (or some other criterion) with more than some number of failed activation attempts getting flagged for apparently attempting to probe the system.
We know from Credit card expiration dates - Inclusive or exclusive? that credit card expires on the last day. However, in which time zone?
In short, even if the current time of the transaction seems suspect, you can just run the card transaction. Let the payment network decide how it wishes to handle the case. This is as stated by Stephen Newell, here, though it isn't necessarily correct to say 'Transaction Server'.
Here's an in-depth on why, and why it is ok to let the network make the decision for you. For merchants (but not cardholders) in countries outside of the U.S. or Canada, some of the following information may not apply.
Expiration Dates and other credentials are subject to the first party in the processing chain to make a decision to reject them. When a credit card transaction is issued, it travels through the following list of parties and then back up to the consumer. If the expiration date makes it all the way down the chain to the last possible point of rejection, then the final decision is up to the issuing bank of the card. But, there are plenty of parties that may decide to reject a transaction, whether or not it is right to do so. Payment gateways or relays, where they exist, often try to preempt interchange decisions on their own.
Card Terminal / Point-of-Sale / Payment Application / Payment Website
Issues Transaction.
One or more Payment Gateway / Payment Relays (where applicable)
Intercepts, Relays/Forwards, or Reroutes a Transaction.
Processors / Settlement Clearinghouses
Filters Transactions, Aggregates Money for the Merchant.
Interchange Network
Routes Authorizations to Issuing Banks, or may Authorize for a Group of Banks
Issuing bank (Visa/MC) / American Express / Discover
Issuer and Primary Authority of Card Credentials
It is worth noting that the major processors in the chain that precede the banks are all based in the United States, in the EST/EDT and CST/CDT time zones. This makes for three possible termination timezones. Any given U.S. timezone is possible, but only a handful of merchants go straight to interchange (Walmart, for example). Everyone else must go through a processor.
Parties in groups #1, #2, #4, #5 are going to be in any timezone you can imagine. For #3, there are two major Processors in the United States that handle settlement. They are First Data (FDR), and Global Payments (GPN). Both are based in the EST/EDT timezone, but most of FDR's gateways are in the CST/CDT timezone.
In order of earliest possible expiration, this gives us the following:
Midnight (12:00am), the first of the next month following the month and year of expiry, in GMT time.
Midnight (12:00am), the first of the next month following the month and year of expiry, in EST or EDT time.
Midnight (12:00am), the first of the next month following the month and year of expiry, in CST or CDT time.
In order of likely cutoff times, #2 and #3 are about equally likely. #1 is far less likely, as this can cause major confusion for merchants in time zones that lag behind the GMT timezone. The difference in CST/EST time is only one hour. If you want to play it safe, you should have few problems going by EST time.
As mentioned by Tony Brandner, there is also the possibility of a delayed capture of the results of a credit card transaction. By interchange rules, this can add up to 30 days for a transaction to be committed for off-line batches for non-airline merchants (Airlines and a few other businesses have really complex rules here). After 30 days, the authorization allowing a transaction will expire. But, this still requires a Merchant to start the transaction prior to card expiry.
Finally, I would find it highly suspect to accept a transaction, especially in a face-to-face customer situation, where a customer has a card labeled within a few hours of expiration. The typical lead-in time for new cards is 1 month, and most issuers try to get a new card to their clients in 2-3 months ahead of expiry. There's little excuse for a client to avoid using a new card, short of some rather unusual circumstances. Plus, you can always ask if the customer has a different card available.
Edit:
Nobody caught me on this, but I should add that the Processors should be considered the major cutoff for a number of reasons. Here are a few of interest.
It is often opaque to almost all parties leading up to the processors, whether a decision issued from a Processor came from someone further in the chain, or the processor itself. Thus the working assumption by people in the payment industry is that the Processor is the authority.
Processors have a vested interest in averting fraud, and they will flag suspect transactions and merchants if they find any. They have the power to freeze Merchant Accounts, freeze transactions, and much more. Resolving adverse reactions as a result of running a suspect transaction will almost always require consultation with the processor, since they are the gatekeepers of money transfer. They are not interested in pushing money around if it may cost them business.
Came across this after doing some testing against the stripe api. It's 4:30 Pacific on Nov 30 and a 11/2015 test failed. 12/2015 worked and Stripe's API is using UTC so it explained the failure. Just in case anyone is wondering. Oh, and changing the timezone in the stripe dashboard doesn't help.
Most forums seem to indicate that you should look at the timezone of the processor. However, since it can take time to process stuff (especially if you're using delayed capture), and most people get replacement cards months in advance, I'm thinking you would want to err on the side of giving yourself a buffer.
If the card expired 'Nov 2009', that translates to the end of Nov 30th, 2009. If you rejected this card starting the very end of Nov 29th, 2009, that would ensure that you're never accepting a card that has expired, regardless of timezone. Would the potential impact to customers be big?
My guess would be wherever the server processing the transaction is located.
Some other merchants, to complete the picture of when they cut off use of card close to expiry:
Amazon - Despite their useless overseas chat support, there is no checking with the bank, but a Javascript lockoff of proceeding with purchase with a tooltip about expiry. Sometime after EST. Checked 30mins before PST.
Paypal - Javascript message about updating expiry date, not locking off Pay button, but not letting that do anything once clicked. Sometime after EST. Checked 30mins before PST.
Walmart - POST of page (seemingly asynchronously), which then amends message about updating expiry date, preventing subsequent clicking of pay button. Not enough time to check with bank, which is in comparison to time used when the payment goes through. Sometime after EST. Checked 30mins before PST.
Our website uses a credit system to allow users to purchase inexpensive digital goods (eg. photos). We use credits, rather than asking the user to pay for items individually, because the items are cheap and we are trying to keep our credit-card/PayPal overhead low.
Because we aren't a bank, we have to expire credits after a certain amount of time. We expire deposit credits after a year, but other types of credits (bonuses, prizes, refunds) may have a different shelf-life. When a buyer buys an item, we spend the credit that is going to expire first.
Our current system keeps track of every deposit by storing the original value and the remainder to be spent. We keep a list of all purchases as well, of course.
I am currently moving to a system which is much more like a traditional double-entry accounting system. A deposit will create a ledger item, increasing the user's 'spending' account balance. Every purchase will also create a ledger item, decreasing the user's 'spending' account balance. The new system has running balances, while the old system does not, which greatly improves our ability to find problems and do reconciliations.
We do not want to use the old system of keeping a 'remainder' value attached to each deposit record because it is inefficient to replay a user's activities to calculate what the remainder of each deposit is over time (for the user's statement).
So, after all of this verbose introduction, my question is "Does anyone else out there have a similar system of expiring credits?" If you could describe how you calculate expired credits it would be a great help.
If all expired credits had the exact same shelf life, we would be able to calculate the expired amount using:
Total Deposits - Total Spending - Deposits Not Due To Expire = Amount to Expire
However, because deposits can have different shelf lives, this formula does not work because more than one deposit can be partially spent at any given time.
No, I don't have a similar system, but it sounds like you should probably add the expired credits to the ledger as debits.
These credits you describe don't sound to me like a currency; they sound more like a financial instrument with an expiration date, like an option or a futures contract. If you use conventional double-entry bookeeping, and account for each instrument individually the same way a financial brokerage would, then things should work out about right.