<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The Problem with B2B Payments</title>
	<atom:link href="http://paymentsviews.com/2009/04/02/the-problem-with-b2b-payments/feed/" rel="self" type="application/rss+xml" />
	<link>http://paymentsviews.com/2009/04/02/the-problem-with-b2b-payments/</link>
	<description>Views and Opinions about the World of Payments</description>
	<lastBuildDate>Wed, 10 Mar 2010 18:51:41 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Dean Procter</title>
		<link>http://paymentsviews.com/2009/04/02/the-problem-with-b2b-payments/comment-page-1/#comment-388</link>
		<dc:creator>Dean Procter</dc:creator>
		<pubDate>Sat, 04 Apr 2009 02:27:10 +0000</pubDate>
		<guid isPermaLink="false">http://paymentsviews.com/?p=1469#comment-388</guid>
		<description>As a developer of payment systems, I read the issues with interest. It seems clear that a simple mechanism to enable buyers to pay is the best option. Ideally there should be no account details to store and the interface (the invoice) must give the buyer the traditional options. ie. pay now = x% discount, pay in 30 days (give credit and set the action in place automatically), pay by card = X% surcharge/discount etc.

If the interface, or invoice (electronic) is smart enough, then the choices are clear for the buyer/payer and the outcome clear to the seller. It is really mostly about knowing where the money is, then you can control your cashflow/credit.

I assume the idea of multiple choices which could include &#039;contact me&#039; would be well received. 

I see interfaces like twitter potentially being useful for simple contact, and the phone is always present.

It is all about making it easier for the user, not limiting choices, perhaps offering more choices and a very simple (and secure) method of performing/authenticating the choice. This allows the boring, risky and time-consuming parts of the process to be eliminated for the users.

The old &#039;store the bank account details&#039; and all that routine is really not the business of business and the banking system is rather flawed in that regard, leading to unpalatable risks for business. Any advanced payment system, either B2B or P2B should really be looking for alternatives which simplify business processes, reduce costs and improve the relationship. The current approach is bound to end in tears for someone.

Ultimately I see offerings whereby the wholesaler might even be paid the instant one of their supplied items is purchased by the the retailer&#039;s customer, perhaps even along with the tax man, if that made it easier for business. The whole supply chain process could be made more efficient.

There will certainly be some strong offerings in the pipeline as the potential is virtually untapped and there are a lot of dollars consumed by the existing processes, and the means to improve them is certainly at hand.

Best regards
Dean Procter</description>
		<content:encoded><![CDATA[<p>As a developer of payment systems, I read the issues with interest. It seems clear that a simple mechanism to enable buyers to pay is the best option. Ideally there should be no account details to store and the interface (the invoice) must give the buyer the traditional options. ie. pay now = x% discount, pay in 30 days (give credit and set the action in place automatically), pay by card = X% surcharge/discount etc.</p>
<p>If the interface, or invoice (electronic) is smart enough, then the choices are clear for the buyer/payer and the outcome clear to the seller. It is really mostly about knowing where the money is, then you can control your cashflow/credit.</p>
<p>I assume the idea of multiple choices which could include &#8216;contact me&#8217; would be well received. </p>
<p>I see interfaces like twitter potentially being useful for simple contact, and the phone is always present.</p>
<p>It is all about making it easier for the user, not limiting choices, perhaps offering more choices and a very simple (and secure) method of performing/authenticating the choice. This allows the boring, risky and time-consuming parts of the process to be eliminated for the users.</p>
<p>The old &#8217;store the bank account details&#8217; and all that routine is really not the business of business and the banking system is rather flawed in that regard, leading to unpalatable risks for business. Any advanced payment system, either B2B or P2B should really be looking for alternatives which simplify business processes, reduce costs and improve the relationship. The current approach is bound to end in tears for someone.</p>
<p>Ultimately I see offerings whereby the wholesaler might even be paid the instant one of their supplied items is purchased by the the retailer&#8217;s customer, perhaps even along with the tax man, if that made it easier for business. The whole supply chain process could be made more efficient.</p>
<p>There will certainly be some strong offerings in the pipeline as the potential is virtually untapped and there are a lot of dollars consumed by the existing processes, and the means to improve them is certainly at hand.</p>
<p>Best regards<br />
Dean Procter</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason Olson</title>
		<link>http://paymentsviews.com/2009/04/02/the-problem-with-b2b-payments/comment-page-1/#comment-373</link>
		<dc:creator>Jason Olson</dc:creator>
		<pubDate>Fri, 03 Apr 2009 16:25:10 +0000</pubDate>
		<guid isPermaLink="false">http://paymentsviews.com/?p=1469#comment-373</guid>
		<description>Hello Carol. 

I found your article to be a good analysis of the issues facing businesses in their efforts to transition from check (cheque, in Canada)  to electronic payments.  

I happen to work for an  electronic payment processing company in Canada called TelPay Inc.  Our company actually developed the first electronic payment systems way back in 1985 (initially by telephone).  That aside, we have developed an electronic payment software for business payments which removes many of the technical ‘hurdles’ you mention in your article.  

I won’t go into detail but one of the major hurdles our software overcomes is the collection and management of suppliers bank account information.  With our software, businesses are not required to collect (or manage) their vendor’s bank account information nor are they required to notify their supplier of the payment (our system will automatically notify the vendor by email or fax).  Our software enables a business to pay any business expense electronically, thus removing the requirement for checks entirely.

For your interest, here is a link to our software demo http://www.telpayforbusiness.ca/ecomm/

It is not available in the United States (yet) but it can facilitate payments from the U.S. into Canada and vice versa.

If you have any thoughts or comments I would appreciate hearing from you or your readers.
Thanks,
Jason</description>
		<content:encoded><![CDATA[<p>Hello Carol. </p>
<p>I found your article to be a good analysis of the issues facing businesses in their efforts to transition from check (cheque, in Canada)  to electronic payments.  </p>
<p>I happen to work for an  electronic payment processing company in Canada called TelPay Inc.  Our company actually developed the first electronic payment systems way back in 1985 (initially by telephone).  That aside, we have developed an electronic payment software for business payments which removes many of the technical ‘hurdles’ you mention in your article.  </p>
<p>I won’t go into detail but one of the major hurdles our software overcomes is the collection and management of suppliers bank account information.  With our software, businesses are not required to collect (or manage) their vendor’s bank account information nor are they required to notify their supplier of the payment (our system will automatically notify the vendor by email or fax).  Our software enables a business to pay any business expense electronically, thus removing the requirement for checks entirely.</p>
<p>For your interest, here is a link to our software demo <a href="http://www.telpayforbusiness.ca/ecomm/" rel="nofollow">http://www.telpayforbusiness.ca/ecomm/</a></p>
<p>It is not available in the United States (yet) but it can facilitate payments from the U.S. into Canada and vice versa.</p>
<p>If you have any thoughts or comments I would appreciate hearing from you or your readers.<br />
Thanks,<br />
Jason</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alistair Duncan</title>
		<link>http://paymentsviews.com/2009/04/02/the-problem-with-b2b-payments/comment-page-1/#comment-371</link>
		<dc:creator>Alistair Duncan</dc:creator>
		<pubDate>Fri, 03 Apr 2009 15:49:17 +0000</pubDate>
		<guid isPermaLink="false">http://paymentsviews.com/?p=1469#comment-371</guid>
		<description>I totally agree with John Hayes.  In all cases where I have seen the banks and card companies implement B2B especially Buyer initiated payments, infrastructure/system changes are needed to implement the solutions. The Acquiring party is often the one with the most changes and they are the ones who see the smallest short term benefits.  There are ways to implement solutions using the existing networks but they mean changing the business model or possibly bypassing some players and the industry is reluctant to make those radical moves.

Alistair</description>
		<content:encoded><![CDATA[<p>I totally agree with John Hayes.  In all cases where I have seen the banks and card companies implement B2B especially Buyer initiated payments, infrastructure/system changes are needed to implement the solutions. The Acquiring party is often the one with the most changes and they are the ones who see the smallest short term benefits.  There are ways to implement solutions using the existing networks but they mean changing the business model or possibly bypassing some players and the industry is reluctant to make those radical moves.</p>
<p>Alistair</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Hayes</title>
		<link>http://paymentsviews.com/2009/04/02/the-problem-with-b2b-payments/comment-page-1/#comment-366</link>
		<dc:creator>John Hayes</dc:creator>
		<pubDate>Fri, 03 Apr 2009 12:28:24 +0000</pubDate>
		<guid isPermaLink="false">http://paymentsviews.com/?p=1469#comment-366</guid>
		<description>Carol,

Good points.  We think the fundimental problem is that the industry is trying fit  B2B parties to the current payment systems, rather than making the systems work for the B2B parties.   The granting of trade credit (A/R, A/P, and the payments) has been part of commerce for thousands of years.  A/P is critical to business -- it is the largest source of capital for more businesses in America (more than bank loans and ower&#039;s equity) primarily because it is both free and flexible on the time of payment.   Any changes in B2B have to honor the traditional requirements.  This is the reason that the modern credit card system has captured only about 3% of B2B trade credit transaction ($600 billion of $20 trillion).  While this is about 30% of credit card volume in the U.S., it is only 3% of trade credit.  Thanks.  John</description>
		<content:encoded><![CDATA[<p>Carol,</p>
<p>Good points.  We think the fundimental problem is that the industry is trying fit  B2B parties to the current payment systems, rather than making the systems work for the B2B parties.   The granting of trade credit (A/R, A/P, and the payments) has been part of commerce for thousands of years.  A/P is critical to business &#8212; it is the largest source of capital for more businesses in America (more than bank loans and ower&#8217;s equity) primarily because it is both free and flexible on the time of payment.   Any changes in B2B have to honor the traditional requirements.  This is the reason that the modern credit card system has captured only about 3% of B2B trade credit transaction ($600 billion of $20 trillion).  While this is about 30% of credit card volume in the U.S., it is only 3% of trade credit.  Thanks.  John</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Erin McCune</title>
		<link>http://paymentsviews.com/2009/04/02/the-problem-with-b2b-payments/comment-page-1/#comment-355</link>
		<dc:creator>Erin McCune</dc:creator>
		<pubDate>Fri, 03 Apr 2009 01:38:58 +0000</pubDate>
		<guid isPermaLink="false">http://paymentsviews.com/?p=1469#comment-355</guid>
		<description>@Chip, I&#039;ll be in Orlando next week and will try to catch your presentation (I&#039;ve got an appointment that overlaps the first 15 min, so I will be late). Reach out to me directly to connect in person some other time during the conference. Just this afternoon I was exchanging messages on Twitter with Marshall England and Tyler Hannon - I met Tyler at Finovate Startup last year.  - Erin</description>
		<content:encoded><![CDATA[<p>@Chip, I&#8217;ll be in Orlando next week and will try to catch your presentation (I&#8217;ve got an appointment that overlaps the first 15 min, so I will be late). Reach out to me directly to connect in person some other time during the conference. Just this afternoon I was exchanging messages on Twitter with Marshall England and Tyler Hannon &#8211; I met Tyler at Finovate Startup last year.  &#8211; Erin</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chip</title>
		<link>http://paymentsviews.com/2009/04/02/the-problem-with-b2b-payments/comment-page-1/#comment-352</link>
		<dc:creator>Chip</dc:creator>
		<pubDate>Thu, 02 Apr 2009 22:35:14 +0000</pubDate>
		<guid isPermaLink="false">http://paymentsviews.com/?p=1469#comment-352</guid>
		<description>Carol,

Thanks for the post.  The myths that you mention are, in fact, what we hear most folk discuss when they think of the B2B space.  In particular, I was intrigued by the following statement from Erin McCune:

““it’s hard to over-emphasize the pain that this problem is causing A/R departments across the country.”

There are few sectors where this statement is more true than in the SMB sector.  While there is proper focus on enterprise adoption, in many scenarios/solutions the SMB is simply ignored (perhaps as a result of the “hub and spoke” issue).

If any of your readers are interested, myself and David Keenan from BankServ will be presenting next week at the NACHA payments conference.  The session is entitled  “ Payments Integration for Small Businesses - B2B Case Study” and is scheduled from 1:45 – 2:45 on Tuesday (as part of the Payments Biz track).  In the session we discuss much of what you have identified in this post as well as providing a case study on trends and research as it relates to the SMB community.

Cheers,

Chip Kahn
CEO, IP Commerce</description>
		<content:encoded><![CDATA[<p>Carol,</p>
<p>Thanks for the post.  The myths that you mention are, in fact, what we hear most folk discuss when they think of the B2B space.  In particular, I was intrigued by the following statement from Erin McCune:</p>
<p>““it’s hard to over-emphasize the pain that this problem is causing A/R departments across the country.”</p>
<p>There are few sectors where this statement is more true than in the SMB sector.  While there is proper focus on enterprise adoption, in many scenarios/solutions the SMB is simply ignored (perhaps as a result of the “hub and spoke” issue).</p>
<p>If any of your readers are interested, myself and David Keenan from BankServ will be presenting next week at the NACHA payments conference.  The session is entitled  “ Payments Integration for Small Businesses &#8211; B2B Case Study” and is scheduled from 1:45 – 2:45 on Tuesday (as part of the Payments Biz track).  In the session we discuss much of what you have identified in this post as well as providing a case study on trends and research as it relates to the SMB community.</p>
<p>Cheers,</p>
<p>Chip Kahn<br />
CEO, IP Commerce</p>
]]></content:encoded>
	</item>
</channel>
</rss>
