I am looking for some good technical overview of how prepaid cards work. This post provides some basic answers but I would like to learn more.
I am helping with a project where we are going to be issuing prepaid cards that end users will use to pay for services. We don’t plan on using any third party processor. We will write our own software.
Can anyone point me to some technical resources so that I can learn more about industry standards? Some of my questions are:
What are standard scheme for the account number?
Barcode: Do they play any role in the card activation? Isn’t it just a code to look up the item at the Point of Sale?
Card activation: Is there more to it than validating that the account number exists in the database and has not been validated before etc.?
Unlock the PIN: Is this the same as flagging the account has been activated?
Thank you in advance!
The account number can be anything. Just don't use a simple incrementing number, such that it's trivial to guess account numbers.
The barcode serves as a sort of UPC for the card, though it'll have both the account number, and identifying information saying "this is a card for retailer X, in the amount of $Y"
The pin prevents someone from simply scanning the barcodes in bulk and "stealing" the amounts. Without the account number AND the pin, the card cannot be activated. Generally the pin is printed on the card under a scratch-off strip, or is otherwise hidden under packaging so that it can't be read without very obvious "damage" to the card or packaging.
Related
I am sorry if this wasn't a good place to ask a question like this, but since I always got help from Stackoverflow I though I could get some answer to my problem.
So here is the thing, I am building a e-commerce website like many famous websites over there, where you can make bid offers for items on the market.
The thing I want to be sure is that when someone place a bid for some item, they can not turn back on their word, because if they get accepted the money should be withdrawn from their bank accounts, do you get what I mean?
Because I want the merchant to be safe if they accept a offer they want the money, and they don't want to look for another legit offer.
So how can I accomplish this?
Should I ask the credit card details when they make the bid offer and only make the withdraw operation from their accounts if the their offer was accepted by the merchant? [using some automated trigger on my database of course]
If this is not the best practice to accomplish this, which is the one??
I am really new into payment methods and I just started doing my search for Payment Gateways (maybe they offer me this functionality... I don't know?!)
You should never store credit card details, and have the details is not really any guarantee of getting paid since the card could just be canceled.
What you are probably looking for is for Authorization and delayed capture (depending on the timeline you are looking at). Different payment processors have different time requirements around how long you can hold an authorization. In general you would make a request with the API to Authorize the charges (kind of like a 'hold' on your credit card) and then later you would either cancel or Capture, where the funds would be transferred. See more info about the process and Square's API here: https://docs.connect.squareup.com/articles/delayed-capture-transactions/
Recently, I received a mail from Google Play Support Team:
This is a notification that the minimum content level of your application, x, with package ID y, has been changed to Medium Maturity (3) by the Google Play Team after a regular review.
REASON FOR CONTENT LEVEL CHANGE: Violation of the Google Play content rating policy.
After a regular review, we have determined that your app includes gambling themes. The content rating of your app has been changed to reflect this content.
Please be advised that additional content rating modifications by the Google Play Team may result in administrative action, up to and including removal of subsequent applications in violation.
All violations are tracked. Serious or repeated violations of any nature will result in the termination of your developer account, and investigation and possible termination of related Google accounts.
We appreciate your contributions towards ensuring an accurate content rating experience for Google Play users.
The Google Play Team
The problem with this mail is that my app is a fitness app where no currency transaction, virtual or real, takes place.
I would like to dispute the unfair content rating given to my app and the unfair threat given to me.
Could any one please help me find an appropriate forum or email where I can forward my dispute?
Thank you!
This is the link I used for a similar email :
https://support.google.com/googleplay/android-developer/answer/2992033?hl=en&ref_topic=3453554
I have not yet gotten an answer.
I'm looking at the possibility of setting up limited acceptance of debit cards online. However, as I research, I see that there are huge differences in the interchange rate between debit cards that are regulated under the recent Durbin amendment and those that are exempt. Depending on my merchant account fee structure, this could give us wildly different costs based on how the transaction gets categorized.
If I'm using authorize.net as the gateway, is it possible to use their API to determine the categorization of the card on the interchange with just an authorize transaction? (and thus accept only cards that I know can be processed cheaply, and give an "i'm sorry" message to everyone else). Is there any other way to identify them without actually making the charge on the card?
Unfortunately there isn't. The rates used to process a transaction are determined at transaction time and are not available via any API. You can only find out what rate was charged by viewing the reporting offered by the merchant account provider.
We are about to develop new mobile application that requires the end user to fill his payment information, which will be redirected to a third party’s portal to pay for a certain services through the application ( using Web Services )
user send billing information using web services , Is this legal for apple ?
It's OK to integrate 3rd party credit card payment systems in your app (for example PayPal, Amazon payments, etc. or your own system) as long as you do not sell services, extensions, etc. to your app. As you say you're going to sell physical goods, it is OK for Apple. Amazon app does the same thing. Btw it is even explicitly prohibited to use in-app payments to sell physical goods.
EDIT: more answer to the detailed questions in the comment
IMHO (see disclaimer):
Shipping fees of physical goods and signup fees for your physical service are NOT services or extensions - in the sense that Apple uses it, it applies only to some additional features to your application, for example a new level in a game or a new map in a mapping app
to be legally store, transmit, process credit card information, you will have to be compliant to the Payment Card Industry Data Security Standard. Here Apple has nothing to do, but both Visa and Mastercard (and maybe also other card issuers) require that you implement these practices if you wish to process credit card data of their cards
this last requirement might be tricky so I really suggest you to look for some ready solution instead of implementing your own. See also the first answer to this question: Use In App Purchase For Real Goods
DISCLAIMER: I am not a legal authority or somebody from Apple so I can give you just hints but not a legal advice - will have to ask a lawyer for an "official" answer :)
Before jumping in I'd like to know what all of my options are, and, if possible their pros and cons.
The two I know of are using ActiveMerchant, or the paypal_recurring gem, but will they satisfy these requirements?
Ability to accommodate monthly and annual billing
Ability to suspend, cancel accounts etc
Deal with out-of-date card details or failed payments
The to-do list for the paypal_recurring gem includes 'adding support for IPN' - how will not having this impact functionality?
I know there is the railskit SaaS but I'd rather code something myself as the railskit is still on 3.2.1.
I know there are services like cheddergedder/chargify etc, but do they tie you in? Are they US only? Are they worth considering - or are they usually just aimed at non-developers?
Thanks in advance.
I just finished going through this, so I'll try to shed some light on your options. I ended up using Paypal Express Checkout for all recurring purchases through Paypal. We had a custom-rolled recurring billing setup that charges a customer's credit card monthly through Authnet, but had to switch because we needed an international solution, and Paypal was one of the only ones that supported the currencies we needed, and wasn't entirely a nightmare to code.
You can use ActiveMerchant for recurring billing with this plugin, though keep in mind that it is not officially a part of ActiveMerchant, and therefore is subject to break if ActiveMerchant changes how it handles certain things. Because of that, I ended up using the paypal-recurring to handle communication through Paypal, and then rolled my own IPN parser, with help from Railscasts. Another link that helped me a lot was this, though all the :txn_type values ended up being different.
With regards to that last link, here are the 4 :txn_types that I specifically watch out for:
express_checkout - first postback.
recurring_payment_profile_created - sent on first postback when the user first subscribes.
recurring_payment_profile_cancel - sent if user cancels subscription from Paypal's site.
recurring_payment - Money has been transferred to your account. This is what I wait for before I renew their subscription on a monthly. This post also comes with payment_status, which needs to be completed.
The other stuff you mentioned, like handling failed payments and out-of-date cards, is handled through your Paypal account.
Just a word of warning - the only reason I ended up using Paypal is because it is universally recognized and trusted, and it accepted international currencies. There is an enormous amount of documentation on their site, and most of it is redundant, confusing, and entirely too long. My recommendation is to make sure you really want/need to deal with recurring payments, as they are difficult to implement correctly and can be more trouble than they're worth.
I'm currently looking at Ryan Bates example of Stripe. They are a California based company that uses/offers the features you have listed.
www.stripe.com
They only charge when you receive money. I think that they are 3% plus $0.30 per successful transaction. Much better than some other companies that have a monthly minimum. Right now you have to have a bank in the USA to use their services as a merchant. However, anyone can use your site with out of the country credit cards.
The SaaS Kit is now tested with Rails 3.2.2. :) It doesn't support IPN yet, but it's on to the todo list. With all the info here in one spot, I suppose I have no excuse not to get it done. :)