3

Business B accepts the credit card information under SAQ-A-EP guidelines and gets the token T back from the payment services provider P. The token now needs to be sent (by B) to partners P1 or P2 or P3. for them to charge the customers of B, for services provided by the partners.

Is this a viable scenario? In other words can a business just forward the token and have the partner add transaction information for processing? If not, how does the business that essentially acts as an intermediary process payment through partners?

1

Is this a viable scenario? In other words can a business just forward the token and have the partner add transaction information for processing?

Generally, no - not because DSS prohibits sharing of a token, but because the token is only useful in the context of the relationship between the processor and the merchant. Random parties P1 - P3 cannot present the token to the processor and have the processor do anything with it; they must themselves have a business relationship with that processor. And the tokens provided by a processor to one merchant may not be portable to other merchants using the same provider.

If not, how does the business that essentially acts as an intermediary process payment through partners?

It sounds like you're looking for something like the Payment Facilitator, or PayFac*, model. It allows merchant B to act as a middleman between P1/P2/P3 (who are "sub-merchants" in this model) and processor P. The PayFac B will generally work to provide interfaces for sub-merchants to route their payment flow through processor P under the auspices of B, and then will take the aggregated monetary distribution from P and distribute the correct breakdown to P1/P2/P3. The Card data and the tokens will stay with B; customers of P1/P2/P3 will flow through B for future transactions (usually without it being obvious that they're doing so).

"Payment Gateway" is one of the terms you might hear used to describe Payment Facilitators, although I will caution that "Payment Gateway" as a phrase also includes a lot of different non-PayFac setups and means different things to different people.

Essentially, P1/P2/P3 are handing over the complexity of dealing with the cards to the PayFac, B. But they have the benefit of enabling their business by accepting cards.


*PayFac is the Vantiv term for this sort of setup; I don't know if there's a generic term or what the names of competing offerings are. Full disclosure, I am a Vantiv employee. Limiting the example to Vantiv is a sign of my ignorance rather than bias per se :). If anyone names competing equivalents in the comments, I'm happy to bubble them up into the answer itself.

  • thank for your the explanation. This confirms my understanding. Payment facilitators would be a good fit. – user9445 Aug 6 '16 at 3:08
  • By saying PayFac you mean payment gateway ? – BokerTov Aug 10 '16 at 6:58
  • @BokerTov I think PayFac is a fully included subset of Payment Gateways, but that Payment Gateway is a large and loosely-defined term that includes all sorts of things that aren't PayFacs. I definitely think it's useful to include that term as part of the answer, and will edit to update. – gowenfawr Aug 10 '16 at 11:51
0

The solution that we are gong to use is to send the token in a EOD file back to the payment provider with the partner information. The partner has to have a relationship with the payment provide too. The payment provider will create a new token for the partner and that will be used for payment processing.

-1

From my experience in PCI and CC's I would say the answer is no based on how you described the scenario for the following reasons:

  1. The business B, shouldn't need to get a token since it should be handled by a third party based on the SAQ-A-EP. All B needs is an approval of the transaction.
  2. Transferring the token will be falling afoul of both storage and transmission of CHD, which fails under SAQ-A-EP.
  3. I believe their is consumer protection clauses around the data you share to partners.

In your scenario, if a consumer orders order services than need to executed by multiple partners, their should either:

  • Be a single transaction, and it be financial divided inter-company, or
  • The consumer should be transferred to each site to execute transactions individually.

Tokens are generally derived using the Merchant ID for tracking purposes.

Note: I am taking partners to mean separate companies sharing a common interest/ providing services to each others consumers. If you in fact had a single entities which was identified by the provider as the merchant, your scenario becomes more plausible, but I think you'd still break SAQ-A-EP.

EDIT:

I know Token are not CHD, and I meant to imply they still needed to be protected and since I this was specific to SAQ-A-EP, token would not be transferable to meet that guideline. Under that scenario you are likely to be placed in SAQ-C or D.

  • -1 for #2 because tokens are explicitly not CHD, which is why we use them. Transferring the token doesn't violate the DSS... (whether P1 - P3 can do anything with that token is a different matter...). And if B had the actual card number and wanted to share it with P1 - P3, they could, according to the DSS, as long as it's done in a compliant manner. (But they wouldn't be A-EP if they had the CHD, natch...) – gowenfawr Aug 5 '16 at 11:47
  • Right tokens are not CHD. – user9445 Aug 6 '16 at 3:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.