Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
You know those websites that let you type in your checking account number and the routing number, and then they can transfer money to and from your account?
How does that work? Any good services or APIs for doing that? Any gotchas?
The banks do have APIs for doing this, but only approved people/companies are allowed to interface with these systems. Because it actually involves transferring money around, the security requirements are pretty high in terms of how you handle the account numbers on your system.
Many sites that offer this feature for buying goods actually use a third party system to handle the actual money transfer into their account. This lowers the amount of trouble to implement the API, as well as putting the burden of security on the third party handling the money transfers.
If you are serious about setting up a system where you can accept bank account numbers, and exchange funds, you should contact your bank, and see what the actual requirements for implementing such a system. Each bank has their own system, along with their own rate regarding the cost of these transactions.
Some third parties I'm aware of are
Moneris
Cactus
Beanstream
I'm in Canada, although I think Moneris and Cactus operate in the US. I think Beanstream doesn't. Again, you can talk to your bank, and they can probably get you in touch with a third party who will help you with the transactions.
If you want to be able to initiate transfer of funds between accounts in different financial institutions (using account and routing number), you need to find a payment processing company that offers ACH (http://en.wikipedia.org/wiki/Automated_Clearing_House) transfer services. Usually these companies are subsidiary of a financial institution that already has access to ACH. For example. one such company is ACH Direct (http://www.achdirect.com/). I can't vouch for its services or reliability though, I am just giving it here as an example of what type of companies you need to search.
Of course, technically, you could try to connect to ACH directly. However, to do this, you need to follow the rules and regulations of NACHA (http://en.wikipedia.org/wiki/NACHA-The_Electronic_Payments_Association) when writing your software and pass rigorous certification. It's quite a big investment, so unless you are backed by couple of bilions of dollars, I wouldn't advise attempting this.
You can do this with a Moneris US eSELECTplus merchant account - you just need to have Automated Clearing House (ACH) enabled on your merchant account (unfortunately there is no equivalent to ACH currently available in Canada).
Here's an example of what a debit transaction looks like in the Moneris US PHP API:
<?php
require "../mpgClasses.php";
/************************ Request Variables **********************************/
$store_id='monusqa002'; //account credentials
$api_token='qatoken';
/************************ Transaction Object******************************/
$txnArray=array(type=>'us_ach_debit',
order_id=>'ach-'.date("dmy-G:i:s"),
cust_id=> 'my cust id',
amount=>'1.00'
);
$achTemplate = array(
sec =>'ppd',
cust_first_name => 'Bob',
cust_last_name => 'Smith',
cust_address1 => '101 Main St',
cust_address2 => 'Apt 102,
cust_city => 'Chicago',
cust_state => 'IL',
cust_zip =>'123456',
routing_num => '490000018',
account_num => '23456',
check_num => '100',
account_type => 'savings'
);
$mpgAchInfo = new mpgAchInfo ($achTemplate);
$mpgTxn = new mpgTransaction($txnArray);
$mpgTxn->setAchInfo($mpgAchInfo);
$mpgRequest = new mpgRequest($mpgTxn);
$mpgHttpPost = new mpgHttpsPost($store_id,$api_token,$mpgRequest);
/************************ Response Object **********************************/
$mpgResponse=$mpgHttpPost->getMpgResponse();
print("\nCardType = " . $mpgResponse->getCardType());
print("\nTransAmount = " . $mpgResponse->getTransAmount());
print("\nTxnNumber = " . $mpgResponse->getTxnNumber());
print("\nReceiptId = " . $mpgResponse->getReceiptId());
print("\nTransType = " . $mpgResponse->getTransType());
print("\nReferenceNum = " . $mpgResponse->getReferenceNum());
print("\nResponseCode = " . $mpgResponse->getResponseCode());
print("\nMessage = " . $mpgResponse->getMessage());
print("\nAuthCode = " . $mpgResponse->getAuthCode());
print("\nComplete = " . $mpgResponse->getComplete());
print("\nTransDate = " . $mpgResponse->getTransDate());
print("\nTransTime = " . $mpgResponse->getTransTime());
print("\nTicket = " . $mpgResponse->getTicket());
print("\nTimedOut = " . $mpgResponse->getTimedOut());
?>
The API files and integration guides for Moneris USA are available at:
http://developer.moneris.com (free registration required)
Moneris USA - ACH:
http://www.monerisusa.com/payment-processing-services/ach-direct-debit.aspx
Stripe Connect allows you to transfer money to bank accounts and to accept payments through one unified API. As of December 2015 they provide more thorough documentation and in general seem to be a more popular option among developers than most of the companies mentioned in other answers.
See https://stripe.com/docs/connect for more info.
Paypal has a fairly accessible API you can use within your program to accomplish some of this.
Pretty straightforward way of doing ACH transfers - https://www.dwolla.com/white-label
Depending on what you want to your application to do you'll need different functionality.
If you want to pay (credit) bank accounts. It's pretty straight forward. Here are the steps:
1. Create a member
2. Create a funding source
3. Create a transfer
If you want to debit and credit bank accounts it gets a little more complex. Here are the steps:
1. Create a member
2. Get a funding source authorization
3. Create a transfer
The only reason the authorization is a little harder is because you have to go through a 2 deposit method or a verification flow of some type. This gets a lot easier with Dwolla.js - https://www.dwolla.com/dwollajs-bank-verification
Related
The call to getSiteInfo returns, among other things, a list of enableContainers.
Each of these is a hash eg: { "containerName":"bills", "assetType":0 }
Is there an exhaustive list of containerNames?
Is there an exhaustive list of assetTypes and what do the enums mean?
I have looked through the Yodlee developer's docco but can't find the answers.
There are couple of things to know about this.
This enabled containers varies depending upon which all containers are enabled for you as a customer, for example if you are interested only in bank and credit cards then this can be configured and irrespective of what other container types Yodlee supports you will get only these two container types.
Exhaustive list- bank, credits(for credit cards), loan/mortgage, bills(can have- minutes,telephone,utilities,cable_satellite,bills), insurance, stocks(for investments), miles(for Rewards) and prepay.
Asset Types- can be of 0,1,2 where all you containers which will have your asset will get 1, containers considered as liabilities will have this value as 2 and rest will have 0.
I have recently been tasked with a small project of setting up a periodic (somewhere between daily & weekly) data dump from an internal database to a 3rd party product. This project dovetails nicely with my company's desire (one which I share) to start standing up a formal service layer/API over the top of our data.
My personal preference is that those APIs should take on the form of RESTful endpoints - however, now I have what I think is a big design question - let me explain...
Looking at the data pull in question, it's hardly complicated. If I were just going to construct a one-off query, it would conceptually look a little something like:
select o.order_num, o.order_date, p.product_description, sr.sales_rep_name
from order o, line_item li, product p, sales_rep sr
where li.order_num = o.order_num
and li.product_id = p.product_id
and sr.sales_rep_id = o.sales_rep_id
and o.order_date >= [some arbitrary date]
Flipping my brain into "Resource Mode", I can think about how to convert this basic data model into URI's/payloads without too much trouble:
GET /orders/123
{
"order_num": 59324,
"order_date": "2014-07-07",
"sales_rep_uri": "/salesRep/34",
"line_items_uri": "/order/123/lineItems"
}
Getting more information about the sales rep:
GET /salesRep/34
{
"sales_rep_name": "Jane Doe",
"open_orders_uri": "/salesRep/34/orders"
}
Getting more information about line items:
GET /orders/123/lineItems
{
"line_items": [
{"order_uri": "/order/123", "product_uri": "/products/68"},
{"order_uri": "/order/123", "product_uri": "/products/99"}
]
}
And so on. I'm not saying it's a perfect API, I'm just trying to demonstrate it's not exactly rocket science to go about thinking how you might express the data model in a nicely normalized, resource-oriented type of way via RESTful URIs. But that is exactly where the design question comes into play...
On one hand, I can crank out a query to solve the problem very easily, but the very nature of queries requires the various domain concepts to be tightly coupled (in other words, utilizing joins to bring all of the normalized data together into one nice, custom-purpose de-normalized structure).
On the other hand, going through the mental process of thinking out a RESTful API leads me right back down that road of keeping things nicely compartmentalized - e.g. asking for "Order 123" shouldn't send me back this huge graph where I can see the full product description, the sales rep's phone number, etc, etc. The concept of a full blown HATEOAS-level RESTful API dictates consumers should be making subsequent GETs to drill down for that kind of detail only as-needed.
My question boils down to this: solving this use case seems really easy to do with a direct query and really difficult to do against a nice & tidy RESTful API (I'm picturing the literally 1000's of individual GETs it would take for me to assemble a weeks worth of data vs the few seconds it would take for the query to run). Is there some elegant subtlety of good RESTful design that I don't understand that would prevent me from seeing a good solution, or am I trying to fit a round peg into a square hole (i.e. REST is not good at pulling big data batches across multiple resources)?
I'm just going to throw this out there as a potential solution:
Conceptually, I treat the results of this query as a resource unto itself - like "orderReport".
Treating this as it's own resource, the API could behave something like:
GET /orderReport/[some arbitrary date]
You could then send back either a 201 Created (if the query is relatively quick running) with a location header like Location: /orderReport/[GUID]. Alternatively, if the query takes a while to run (I honestly don't know if it does or not off the top of my head), you could send back a 202 Accepted with a location header of Location: /orderReport/[GUID]/status.
You could then do follow up GETs against those URLs to get either the report status (200 OK if still processing without error, 201 Created with location header pointing to the report URL if its done) or the report itself.
There's nothing to say the report data couldn't also incorporate HATEOAS in addition to the data strictly needed to fulfill the use case requirements, like:
{
[
{
"order_num": 123,
"order_uri": "/orders/123",
"order_date": 2014-07-03,
"product_description": "widget",
"sales_rep_name": "Jane Doe",
"sales_rep_uri": "/salesRep/34"
},
{
"order_num": 456,
"order_uri": "/orders/456",
"order_date": 2014-07-04,
"product_description": "gadget",
"sales_rep_name": "Frank Smith",
"sales_rep_uri": "/salesRep/53"
}
]
}
I'm in the process of building an online marketplace which sells shippable goods. The site will be similar to Etsy, which will connect merchants with buyers.
I'd like to be able to charge a customer's card ONLY when an item is shipped by a merchant to avoid chargebacks and provide an Amazon-like payment experience. This will also help us avoid chargebacks and payment disputes in case a merchant is slow to ship or flakes out. In some cases, the goods will take more than 7 days to be custom manufactured and shipped out
Here's an example timeline:
1/1/2014 - Customer adds $75 worth of items to their cart and clicks "buy". Enters credit card info.
1/1/2014 - Customer's card is verified and a $75 temporary hold is placed on their card. Order is sent to merchant for fulfillment.
1/14/2014 - Merchant ships goods to customer and adds shipping tracking info
1/14/2014 - Customer's card is charged for the full amount and merchant receives $75 minus fees.
I plan to use Stripe Connect for payment processing, but am not sure how to delay capturing a payment for more than 7 days. Any thoughts? I don't want to aggregate the funds under my own account and use payouts since this will likely run afoul of money transmission laws. Any help would be appreciated!
EDIT: It looks like Quora has a similar question here , but the answers don't seem to deal with the case where a merchant ships out the item but the payment fails.
After further research, it seems there's no way to delay capturing a charge past the 7 day authorization window.
But here's one way to delay a charge:
Tokenize a credit card using the stripe.js library
Create a new stripe customer passing in the token as the "card" param
An example from the Stripe FAQ: https://support.stripe.com/questions/can-i-save-a-card-and-charge-it-later
Note that the longer you wait between tokenizing a card and actually charging it, the more likely your charge will be declined for various reasons (expired card, lack of funds, fraud, etc). This also adds a layer of complexity (and lost sales) since you'll need to ask a buyer to resubmit payment info.
I'd still like to confirm that a certain amount can be charged (like a "preauthorization"), but this lets me at least charge the card at a later date.
Celery has built a service to help you do this with Stripe. They are very easy to use, but note that they charge 2% per transaction.
actually you can save user token and pay later with tracking info
# get the credit card details submitted by the form or app
token = params[:stripeToken]
# create a Customer
customer = Stripe::Customer.create(
card: token,
description: 'description for payinguser#example.com',
email: 'payinguser#example.com'
)
# charge the Customer instead of the card
Stripe::Charge.create(
amount: 1000, # in cents
currency: 'usd',
customer: customer.id
)
# save the customer ID in your database so you can use it later
save_stripe_customer_id(user, customer.id)
# later
customer_id = get_stripe_customer_id(user)
Stripe::Charge.create(
amount: 1500, # $15.00 this time
currency: 'usd',
customer: customer_id
)
Stripe release a delay method to place a hold without charging. https://stripe.com/docs/payments/capture-later
<?php
require_once('stripe-php/init.php');
\Stripe\Stripe::setApiKey('your stripe key');
$token = $_POST['stripeToken'];
$stripeinfo = \Stripe\Token::retrieve($token);
$email = $stripeinfo->email;
$customer = \Stripe\Customer::create(array(
"source" => $token,
"email" => $email)
);
?>
If I already have the bank account token (id returned by balanced.js), do I need to do a get to credit the account?
The documentation at:
https://docs.balancedpayments.com/current/api.html?language=php#credit-an-existing-bank-account
says: To credit an existing bank account, you simply pass the amount to the nested credit endpoint of a bank account. The credits_uri is a convenient uri provided so that you can simply issue a POST with the amount and a credit shall be created.
But the example given below it, does a get on bank account first and then a credit.
How do I post to the credits_uri with the amount and other parameters without first doing a get?
If you don't want to get a GET first, you would need to store the credits_uri of the bank account in question and then POST directly to that. e.g.
$credit = new \Balanced\Credit(array(
"uri" => "/v1/bank_accounts/BA123123/credits", // the credits_uri from the bank account
"amount" => 100
))->save();
I am new to use balanced payments.
After get credit card info what is first, second... all steps..
can any one give me step by step so i can do on that way.
Thanks in advance
The steps would depend on what type of application you're trying to develop.
The basis of the system is that you create a Customer for each of your users. balanced.js removes the need for you to be PCI compliant because the sensitive data is submitted directly to Balanced and never goes through your servers. You use balanced.js to tokenize credit cards and bank accounts and add them to specific Customer instances. Once you've got the cards and bank accounts added you can do things like debit customerBuyerA and credit customerSellerB.
Next, I encourage you to read through some of the common fee scenarios to get an idea of what's going to work well for your business. https://docs.balancedpayments.com/current/#collecting-your-fees
Both https://docs.balancedpayments.com/current/overview.html and https://docs.balancedpayments.com/current/api.html have plenty of information to get you going from there.
I encourage you to stop by #balanced on IRC to get any other development questions answered.
I solved using below code in test mode (in RUBY):
Install gem "balanced"
Assign API key
Balanced.configure('API KEY')
Accept user card info
card = Balanced::Card.new( :card_number => "4111111111111111",
:expiration_month => "12",
:expiration_year => "2020"
).save
Create buyer to debit fee
buyer = Balanced::Marketplace.my_marketplace.create_buyer(:card_uri => card.uri)
5 Debit from buyer account
`another_debit = buyer.debit(
:amount => 1000,
:appears_on_statement_as => "MARKETPLACE.COM"
)`
7 Credit to Merchant account (You need to verify Bank account first from here)
merchant = Balanced::Account.find('/v1/marketplaces/TEST-MP6wn7oEW117Yn9gKXuQaTIO/bank_accounts/BANK ACC ID')
merchant.credit('1000')
Hope work for any one and suggestion welcome.