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.
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/
I'm looking for a way to allow our clients to do recurring payments to discount these payments based on the credit in their account which can be earned or deposited in many ways. For example, if they need to pay $20 and have $5 in credit, I would like to only bill the remaining $15 automatically without any need for additional website visits.
Looking at the documentation for PayPal's REST APIs, I don't see any clear way to do this. Is the only way to do this to send them a refund automatically? Or is there a way to get approved to bill clients up to X amount per month but allow us to bill under that amount. I thought billing agreements would allow for this, but after reading the documentation, I'm unable to figure out a way to do it. If it's possible, could someone walk me through what API calls would be needed to do this?
Thanks for any help you can offer.
There are a couple of different ways you could do this sort of thing, but I would avoid the REST API for now. It's still too new and doesn't provide as much functionality and features as the classic API.
Within the classic API, you can use either use Preapproved Payments, which consists of Preapproval and Pay APIs, or you could just use Express Checkout and/or Payments Pro with Reference Transactions.
Either way you'd basically be building your own recurring payments system where you'd setup a billing agreement and then your app would trigger the variable amount payments accordingly.
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.
I have a bit of a conundrum with my Rails application. It looks like the model we are going to use for billing is per-use as opposed to a subscription basis (at least initially). While we've already implemented Recurly's Transparent Post API (great product), it's likely overkill.
We could simply establish a free plan with no monthly charge and then initiate one time transactions. This satisfies the level of PCI Compliance we are looking for and also allows returning customers to have their credit card information stored by a third party.
To further complicate things, there may be a requirement in the future for subscription based plans in addition to the per-use billing. I am looking for some advice about whether to stay with the recurring billing platform or whether I might want to simply use ActiveMerchant, not store credit cards and deal with the change in PCI Compliance (onus is on us and not a third party). Also wondering if there is another tool that handles one-time repeatable transactions without having a subscription plan?
You could use ActiveMerchant with Authorize.net CIM or Braintree to store the card info for you (for the PCI compliance) and run transactions for whatever amount at whatever time based on the token you would get back from either of those. That wouldn't preclude from adding on the recurring billing later -- you would just start charging against those stored tokens on an automated basis.
The SaaS Rails Kit (which I wrote) takes this approach for doing both the recurring billing and one-off transactions.
I'm building a marketplace application:
The customer pays the seller on the marketplace
The marketplace takes a cut of the payment
I would have a payment processing system with the following features
The cut and the 100%-cut are sent directly to the marketplace and seller accounts (ie, I don't want to have 100% on the marketplace account and then to forward the 100%-cut to the seller)
I would love to have a UI as much integrated with the marketplace website as possible. This implies that the customer in the worst case has to put only name, surname and credit card number on the payment processor interface (the ideal would be a payment interface totally integrated with our website)
I don't want to force the customer to register to any third party service
It should work nicely with Ruby on Rails
It should work for non US-based companies and should support multicurrency payments
What are the options out there?
Thanks.
I'd recommend you look at our product Balanced. It's built to solve exactly this problem so I think it's a good match.
At a high level payments in are done via credit card like a normal payment processor, funds are deposited into an escrow account which is a sum of all funds collected - all funds disbursed. When you're ready to push funds out you can currently pay out via next-day ACH (US only) but we're building out international support which sounds like it would be useful for you.
I believe it matches your other requirements:
there is no requirement to send users offsite, they do require accounts but you can create and edit them via the API.
Balanced has an excellent ruby gem
You can split up the payment, taking a cut from the proceeds as profit
Balanced provides you with a merchant dashboard for you and your customers to get a head start but you can build the exact same thing via API access.
One area where it's not going to meet your requirements is multi-currency charges. Currently you'll need to charge in USD and convert.
Check out https://github.com/drhenner/ror_ecommerce It doesn't have all the features you want but will give you a big head start.
Basically active merchant will connect to most gateways. You need to add the custom code. Look at the video for more help http://ror-e.com/info/videos/1