<?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: Credit card processing flow &#8211; the transactions</title>
	<atom:link href="http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/2010/07/credit-card-processing-flow-the-transactions/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/2010/07/credit-card-processing-flow-the-transactions/</link>
	<description>Your credit card processing information source</description>
	<lastBuildDate>Thu, 02 Feb 2012 17:15:54 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: CCPrUs</title>
		<link>http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/2010/07/credit-card-processing-flow-the-transactions/comment-page-1/#comment-13045</link>
		<dc:creator>CCPrUs</dc:creator>
		<pubDate>Mon, 29 Aug 2011 21:23:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/?p=329#comment-13045</guid>
		<description>Dana,

It depends… though in most cases the answer would be much different than your initial assumptions:

Most US merchants offering local currency pricing manage the related FX risk either internally or via an outsourced service (such as E4X). To do so, they have signed up for Multi-Currency processing (with Paymentech or otherwise) and receive from their acquirer the Local Currency Processed – in your example – GBP.

This means that at the transactional level no conversion occurred!

A transaction in GBP was submitted to the customer’s UK issuing bank, processed and paid in GBP to the merchant (using the association network and the US acquirer). As Neither Paymentech nor Visa (or MC) performed a conversion, no conversion fee was charged, and yet a cross border transaction fee, as fully explained at &quot;&lt;a href=&quot;http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/2009/10/how-to-avoid-cross-border-transaction-fees/&quot; rel=&quot;nofollow&quot;&gt;How to avoid cross border transaction fees&lt;/a&gt;&quot;, was charged, due to the fact that the issuing bank (in the UK) and the acquiring bank (in the US) reside in different processing regions… :( 

E4X manages the FX risk. Merchants using E4X receive guaranteed rates in advance, and use same rates to calculate the local currency pricing offered, eliminating currency fluctuations out of the equation…

The confusion (or mix of opinions) is probably related to the fact that other (less common) scenarios exist. In principle, in any event that the merchant is not set up for Multi-Currency Settlement and still offers his products/services in local currencies, a conversion occurs.

Different players may perform the conversion. Paymentech (for example) offers a non-protected conversion service in which the processing flow is identical to the above, but the fact that on settlement the local currencies processed are converted into USD by Paymentech. Surely in this example it is Paymentech who gains the conversion fee, though no hedging services are provided. 

The associations would perform the conversion in case the US acquirer is not set up for Multi-Currency Settlement or when the currency processed is not one of the associations&#039; settlement currencies.

Gidi.</description>
		<content:encoded><![CDATA[<p>Dana,</p>
<p>It depends… though in most cases the answer would be much different than your initial assumptions:</p>
<p>Most US merchants offering local currency pricing manage the related FX risk either internally or via an outsourced service (such as E4X). To do so, they have signed up for Multi-Currency processing (with Paymentech or otherwise) and receive from their acquirer the Local Currency Processed – in your example – GBP.</p>
<p>This means that at the transactional level no conversion occurred!</p>
<p>A transaction in GBP was submitted to the customer’s UK issuing bank, processed and paid in GBP to the merchant (using the association network and the US acquirer). As Neither Paymentech nor Visa (or MC) performed a conversion, no conversion fee was charged, and yet a cross border transaction fee, as fully explained at &#8220;<a href="http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/2009/10/how-to-avoid-cross-border-transaction-fees/" rel="nofollow">How to avoid cross border transaction fees</a>&#8220;, was charged, due to the fact that the issuing bank (in the UK) and the acquiring bank (in the US) reside in different processing regions… <img src='http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/wp-includes/images/smilies/icon_sad.gif' alt=':(' class='wp-smiley' />  </p>
<p>E4X manages the FX risk. Merchants using E4X receive guaranteed rates in advance, and use same rates to calculate the local currency pricing offered, eliminating currency fluctuations out of the equation…</p>
<p>The confusion (or mix of opinions) is probably related to the fact that other (less common) scenarios exist. In principle, in any event that the merchant is not set up for Multi-Currency Settlement and still offers his products/services in local currencies, a conversion occurs.</p>
<p>Different players may perform the conversion. Paymentech (for example) offers a non-protected conversion service in which the processing flow is identical to the above, but the fact that on settlement the local currencies processed are converted into USD by Paymentech. Surely in this example it is Paymentech who gains the conversion fee, though no hedging services are provided. </p>
<p>The associations would perform the conversion in case the US acquirer is not set up for Multi-Currency Settlement or when the currency processed is not one of the associations&#8217; settlement currencies.</p>
<p>Gidi.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dana</title>
		<link>http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/2010/07/credit-card-processing-flow-the-transactions/comment-page-1/#comment-13008</link>
		<dc:creator>Dana</dc:creator>
		<pubDate>Mon, 29 Aug 2011 17:18:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/?p=329#comment-13008</guid>
		<description>Gidi,

I&#039;m trying to fully understand the transactional flow of an international credit card purchase. For example:
 
A UK Consumer shops (using his credit card) at a US site.
The products are priced in his local (UK) currency.

THEN where does it go and who gets what? So I need to know in terms of fees, does the global processor (like Paymentech) get the conversion fee or does Visa/MC get the conversion fee? If Visa/MC gets it, what does the processor get? What does the consumer pay for conversion fees? Also who actually does the conversion PAYMENTECH or VISA? 

Dana</description>
		<content:encoded><![CDATA[<p>Gidi,</p>
<p>I&#8217;m trying to fully understand the transactional flow of an international credit card purchase. For example:</p>
<p>A UK Consumer shops (using his credit card) at a US site.<br />
The products are priced in his local (UK) currency.</p>
<p>THEN where does it go and who gets what? So I need to know in terms of fees, does the global processor (like Paymentech) get the conversion fee or does Visa/MC get the conversion fee? If Visa/MC gets it, what does the processor get? What does the consumer pay for conversion fees? Also who actually does the conversion PAYMENTECH or VISA? </p>
<p>Dana</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: CCPrUs</title>
		<link>http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/2010/07/credit-card-processing-flow-the-transactions/comment-page-1/#comment-5894</link>
		<dc:creator>CCPrUs</dc:creator>
		<pubDate>Thu, 04 Nov 2010 17:36:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/?p=329#comment-5894</guid>
		<description>A “Sale” transaction is used when the two (Authorize and Capture transactions) are performed in a single-step.

Most merchants would do better sending authorization first, analyzing the transaction risk, preferably via a fully automated process, using the data gathered prior to authorization and authorization result (including AVS and 3Dsecure), then, should transaction pass as legit, capture the transaction.

Some digital good online merchants can process on the fly using a “Sale” transaction, yet such is surely NOT RECOMMENDED to physical good merchants, such as Funny T Shirts…</description>
		<content:encoded><![CDATA[<p>A “Sale” transaction is used when the two (Authorize and Capture transactions) are performed in a single-step.</p>
<p>Most merchants would do better sending authorization first, analyzing the transaction risk, preferably via a fully automated process, using the data gathered prior to authorization and authorization result (including AVS and 3Dsecure), then, should transaction pass as legit, capture the transaction.</p>
<p>Some digital good online merchants can process on the fly using a “Sale” transaction, yet such is surely NOT RECOMMENDED to physical good merchants, such as Funny T Shirts…</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Funny T Shirts</title>
		<link>http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/2010/07/credit-card-processing-flow-the-transactions/comment-page-1/#comment-5220</link>
		<dc:creator>Funny T Shirts</dc:creator>
		<pubDate>Thu, 04 Nov 2010 14:57:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/?p=329#comment-5220</guid>
		<description>Processing for a long time and never heard of “Authorization” or “Capture” transactions. We sell T-shirts online and use “Sale” transactions each time we sell.  How can it be that “Sale transaction” does not show on your transactions flow?</description>
		<content:encoded><![CDATA[<p>Processing for a long time and never heard of “Authorization” or “Capture” transactions. We sell T-shirts online and use “Sale” transactions each time we sell.  How can it be that “Sale transaction” does not show on your transactions flow?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Debt Counseling</title>
		<link>http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/2010/07/credit-card-processing-flow-the-transactions/comment-page-1/#comment-5519</link>
		<dc:creator>Debt Counseling</dc:creator>
		<pubDate>Wed, 27 Oct 2010 00:37:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/?p=329#comment-5519</guid>
		<description>Multiply authorization requests occasionally  generate artificial debt, that ends with real fines and loss of funds. Though credit and debit card rules keeps changing (mostly) for the better for consumers, this issue is yet to be resolved.</description>
		<content:encoded><![CDATA[<p>Multiply authorization requests occasionally  generate artificial debt, that ends with real fines and loss of funds. Though credit and debit card rules keeps changing (mostly) for the better for consumers, this issue is yet to be resolved.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: CCPrUs</title>
		<link>http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/2010/07/credit-card-processing-flow-the-transactions/comment-page-1/#comment-2868</link>
		<dc:creator>CCPrUs</dc:creator>
		<pubDate>Fri, 30 Jul 2010 19:07:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/?p=329#comment-2868</guid>
		<description>Different wireless terminals, including &lt;a href=&quot;http://www.creditcardprocessing-r-us.com/iphone-credit-card-app/&quot; rel=&quot;nofollow&quot;&gt;iPhone credit card applications&lt;/a&gt;, do handle transactions differently, at least as long as it relates to PCI compliance.

Some enable non-secured storage of credit card information, while others encrypt all credit cards data on card swipe.

These differences though, would not help you block a fraudulent transaction.</description>
		<content:encoded><![CDATA[<p>Different wireless terminals, including <a href="http://www.creditcardprocessing-r-us.com/iphone-credit-card-app/" rel="nofollow">iPhone credit card applications</a>, do handle transactions differently, at least as long as it relates to PCI compliance.</p>
<p>Some enable non-secured storage of credit card information, while others encrypt all credit cards data on card swipe.</p>
<p>These differences though, would not help you block a fraudulent transaction.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: CONZIE</title>
		<link>http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/2010/07/credit-card-processing-flow-the-transactions/comment-page-1/#comment-2784</link>
		<dc:creator>CONZIE</dc:creator>
		<pubDate>Fri, 30 Jul 2010 18:23:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/?p=329#comment-2784</guid>
		<description>As a merchant I’d love to capture ALL the transactions coming my way, yet learning the hard way, I now know better… and would love to know more!

Is one wireless terminal better than the other in blocking fraudulent transactions?</description>
		<content:encoded><![CDATA[<p>As a merchant I’d love to capture ALL the transactions coming my way, yet learning the hard way, I now know better… and would love to know more!</p>
<p>Is one wireless terminal better than the other in blocking fraudulent transactions?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brandon</title>
		<link>http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/2010/07/credit-card-processing-flow-the-transactions/comment-page-1/#comment-2814</link>
		<dc:creator>Brandon</dc:creator>
		<pubDate>Tue, 27 Jul 2010 23:01:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/?p=329#comment-2814</guid>
		<description>Contacting the seller *should* work pretty easily.

If you need the funds now, then don&#039;t just sit there and let the hold expire.. I had a video store membership hold on my credit card for 6 months several years ago, they simply forgot to take it off, and it came back to bite me.  
</description>
		<content:encoded><![CDATA[<p>Contacting the seller *should* work pretty easily.</p>
<p>If you need the funds now, then don&#8217;t just sit there and let the hold expire.. I had a video store membership hold on my credit card for 6 months several years ago, they simply forgot to take it off, and it came back to bite me.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: http://featuringhost.com/e-commerce-web-hosting-can-get-your-online-business-up-and-running</title>
		<link>http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/2010/07/credit-card-processing-flow-the-transactions/comment-page-1/#comment-2744</link>
		<dc:creator>http://featuringhost.com/e-commerce-web-hosting-can-get-your-online-business-up-and-running</dc:creator>
		<pubDate>Sat, 24 Jul 2010 17:04:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/?p=329#comment-2744</guid>
		<description>[...] We placed your article on our site - thanks! [...]</description>
		<content:encoded><![CDATA[<p>[...] We placed your article on our site &#8211; thanks! [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: CCPrUs</title>
		<link>http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/2010/07/credit-card-processing-flow-the-transactions/comment-page-1/#comment-2722</link>
		<dc:creator>CCPrUs</dc:creator>
		<pubDate>Thu, 22 Jul 2010 19:47:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.creditcardprocessing-r-us.com/Credit_Card_Processing_Blog/?p=329#comment-2722</guid>
		<description>Patrick, you can wait and let the authorization hold die for natural causes… or be proactive.

Authorization hold may take up to 30 days to clear, depending on card and issuing bank. Debit cards would usually clear within 5 days, while credit cards authorization holds would take longer to clear out.

If you need the money, try one of the following approaches:

1.	Contact the seller and request an “Authorization Reversal”.
Some merchants can easily accommodate, while others just don’t have the button you’re after…! All merchants can call the acquiring bank and ask for (manual) reversal, yet if you hit a wall, try plan B -

2.	File a chargeback with your issuing bank.
Though chargeback is used to reverse a Capture transaction, and in your case, no transaction was captured… Still, in most cases, this will expedite the release of your funds.</description>
		<content:encoded><![CDATA[<p>Patrick, you can wait and let the authorization hold die for natural causes… or be proactive.</p>
<p>Authorization hold may take up to 30 days to clear, depending on card and issuing bank. Debit cards would usually clear within 5 days, while credit cards authorization holds would take longer to clear out.</p>
<p>If you need the money, try one of the following approaches:</p>
<p>1.	Contact the seller and request an “Authorization Reversal”.<br />
Some merchants can easily accommodate, while others just don’t have the button you’re after…! All merchants can call the acquiring bank and ask for (manual) reversal, yet if you hit a wall, try plan B -</p>
<p>2.	File a chargeback with your issuing bank.<br />
Though chargeback is used to reverse a Capture transaction, and in your case, no transaction was captured… Still, in most cases, this will expedite the release of your funds.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

