Tokenizzazione della carta di credito e più parti

La soluzione che dobbiamo utilizzare è inviare il token in un file EOD al fornitore di servizi di pagamento con le informazioni del partner. Anche il partner deve avere una relazione con il pagamento. Il fornitore di pagamenti creerà un nuovo token per il partner e verrà utilizzato per l'elaborazione dei pagamenti.

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

Generalmente no - non perché DSS proibisce la condivisione di un token, ma poiché il token è utile solo nel contesto della relazione tra il processore e il commerciante . Le parti casuali P1 - P3 non possono presentare il token al processore e fare in modo che il processore faccia qualcosa con esso; devono avere loro stessi una relazione commerciale con quel processore. E i token forniti da un processore a un commerciante potrebbero non essere portabili ad altri commercianti che utilizzano lo stesso provider.

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

Sembra che tu stia cercando qualcosa come Facilitatore dei pagamenti o PayFac *, modello . Consente al commerciante B di agire come intermediario tra P1 / P2 / P3 (che sono "sub-commercianti" in questo modello) e processore P. Il PayFac B lavorerà generalmente per fornire interfacce per i sub-commercianti per instradare il loro flusso di pagamento attraverso processore P sotto gli auspici di B, e quindi prenderà la distribuzione monetaria aggregata da P e distribuirà la ripartizione corretta a P1 / P2 / P3. I dati della carta e i token rimarranno con B; i clienti di P1 / P2 / P3 passeranno attraverso B per transazioni future (di solito senza che sia ovvio che lo stanno facendo).

" Gateway di pagamento " è uno dei termini che potresti sentire usato per descrivere Facilitatori di pagamento, anche se avvertirò che "Payment Gateway" come frase include anche molte diverse configurazioni non PayFac e significa cose diverse per persone diverse.

Essenzialmente, P1 / P2 / P3 stanno cedendo la complessità di gestire le carte con il PayFac, B. Ma hanno il vantaggio di abilitare la propria attività accettando le carte.

* PayFac è il termine Vantiv per questo tipo di configurazione; Non so se esiste un termine generico o quali sono i nomi delle offerte concorrenti. Divulgazione completa, sono un impiegato Vantiv. Limitare l'esempio a Vantiv è un segno della mia ignoranza piuttosto che un pregiudizio di per sé :). Se qualcuno nomina equivalenti in competizione nei commenti, sono felice di metterli in bolla nella risposta stessa.

Dalla mia esperienza in PCI e CC direi che la risposta non è basata su come hai descritto lo scenario per i seguenti motivi:

1. L'azienda B, non dovrebbe avere bisogno di ottenere un token poiché dovrebbe essere gestita da una terza parte basata sul SAQ-A-EP. Tutte le necessità di B sono un'approvazione della transazione.
2. Il trasferimento del token cadrà in conflitto sia con la memorizzazione che con la trasmissione di CHD, che fallisce sotto SAQ-A-EP.
3. Credo che siano clausole di protezione dei consumatori in merito ai dati che condividi ai partner.

Nel tuo scenario, se un consumatore ordina servizi di ordine che devono essere eseguiti da più partner, è necessario:

• Sii una singola transazione e divisa finanziaria tra le società o
• Il consumatore dovrebbe essere trasferito su ciascun sito per eseguire le transazioni individualmente.

I token sono generalmente derivati utilizzando l'ID commerciante per scopi di monitoraggio.

Nota: sto prendendo partner per significare società separate che condividono un interesse comune / fornire servizi ai rispettivi consumatori. Se in effetti avessi una singola entità che è stata identificata dal fornitore come il commerciante, lo scenario diventa più plausibile, ma penso che tu ancora rompessi SAQ-A-EP.

EDIT:

So che Token non è CHD, e volevo sottintendere che dovevano ancora essere protetti e poiché questo era specifico per SAQ-A-EP, il token non sarebbe trasferibile per soddisfare tale linea guida. In questo scenario è probabile che tu venga inserito in SAQ-C o D.