An Ultimate Reference Guide For Merchant Accounts Jay Wigdore


Presentation Description

A merchant account is a type of bank account that allows businesses to accept payments in multiple ways, typically debit or credit cards. ... In some cases a payment processor, independent sales organization (ISO), or member service provider (MSP) is also a party to the merchant agreement.


Presentation Transcript

Electronic payments:

Electronic payments Jay Wigdore is credit card processing expert.


2 Outline credit card payments over the Internet using SSL using SET electronic cash Chaum’s untraceable e-cash based on blind signatures detection of double spending micropayments the PayWord scheme probabilistic payment schemes of Micali and Rivest

Credit card payment using SSL:

3 Credit card payment using SSL the user visits the merchant’s web site and selects goods/services to buy state information may be encoded in cookies or in specially constructed URLs or state information may be stored at the merchant and referenced by cookies or specially constructed URLs the user fills out a form with his credit card details the form data is sent to the merchant’s server via an SSL connection merchant’s server is authenticated transmitted data is encrypted the merchant checks the solvency of the user if satisfied, it ships the goods/services to the user clearing happens later SSL


4 Problems eavesdropping credit card numbers is not the real risk the real risk is that credit card numbers are stolen from the merchant they might be obtained by breaking in the merchant’s computer on which the numbers are stored this happened with CD Universe in ???? who should care about this? the users are liable only for a fixed amount the issuer bank pays for the fraud  banks (and indirectly credit card companies) should care SSL

SET – Secure Electronic Transactions:

5 SET – Secure Electronic Transactions a protocol designed to protect credit card transactions on the Internet initiated and promoted by MasterCard and Visa many companies were involved in the development of the specifications (IBM, Microsoft, Netscape, RSA, VeriSign, …) the SET specification consists of three books: 1. Business Description 2. Programmer’s Guide 3. Formal Protocol Definition around 1000 pages SET

SET services:

6 SET services confidentiality cardholder account and payment information is secured as it travels across the network cardholder account and payment information (e.g., credit card number) is hidden from the merchant too ! integrity messages cannot be altered in transit in an undetectable way based on digital signatures cardholder account authentication merchant can verify that the client is a legitimate user of the card based on X.509 certificates merchant authentication client can authenticate the merchant and check if it is authorized to accept payment cards based on X.509 certificates SET


7 Model Internet payment network cardholder merchant payment gateway issuer acquirer order info + payment instruction authorization request authorization response + capture token ack + services authorization processing capture processing capture request capture response money transfer SET

SET participants:

8 SET participants cardholder wants to buy something from a merchant on the Internet authorized holder of payment card issued by an issuer merchant sells goods/services via a Web site or by e-mail has a relationship with an acquirer issuer issues payment cards responsible for the payment of the dept of the cardholders acquirer maintains accounts for merchants processes payment card authorizations and payments transfers money to the merchant account, reimbursed by the issuer payment gateway interface between the Internet and the existing bankcard payment network for authorization and payment functions CAs SET

Dual signature:

9 Dual signature links two messages that are intended for two different recipients data1 data2 hash hash hash sign K -1 X data1 data2 SET

Payment processing overview:

10 Payment processing overview cardholder (C) merchant (M) payment gtw (P) C OI C PI K P M Auth.Req. K P C PI K P P Auth.Res. K M P Cap.Token K P M Ack P Cap.Token K P M Cap.Req. K P P Cap.Res. K M * * * C OI Order Info. PI Payment Inst. signature dual signature digital envelop M K P SET

Untraceable e-cash:

11 Untraceable e-cash electronic coins: ( serial_number, Sig K -1 bank (serial_number) ) problem of traceability user merchant bank withdraw coin sn (user is identified in order to debit her account) deposit coin sn (merchant is identified in order to credit his account) spend coin sn bank can link the withdrawal (identity of the user) and the deposit (identity of the merchant) via the serial number sn e-cash

Untraceable e-cash cont’d:

12 Untraceable e-cash cont’d making it untraceable: blinded RSA signatures U generates a random number r U computes h(coin_data) * r PK(B) and sends it to B B signs the blinded coin by computing ( h(coin_data) * r PK(B) ) SK(B) = h(coin_data) SK(B) * r when U receives the blindly signed coin it removes the blinding h(coin_data) SK(B) * r * r -1 = h(coin_data) SK(B) the rest of the protocol (spending and deposit) is the same as before the bank cannot link r * h(coin_data) SK(B) and h(coin_data) SK(B) together (r is random) e-cash


13 Micropayments special payment protocols developed for very low value transactions usual examples include paying for web pages visited paying for downloaded fragments of a song, movie paying for news, articles from a digital journal encourage sharing in peer-to-peer networks … not very successful so far people are used to get these kind of things free of charge if they have to pay, they prefer the subscription model micropayments


14 PayWord representative member of the big family of hash chain based micropayment schemes players user (U) vendor (V) broker (B) credit based payment tokens are redeemed off-line uses public key crypto, but very efficiently (in case of many consecutive payments to the same vendor) user signs a single message at the beginning this authenticates all the micropayments to the same vendor that will follow developed by Rivest and Shamir in 1996 micropayments

Registration phase:

15 Registration phase U registers with a broker B B issues a certificate for U C U = { B, U, addr U , K U , exp, more_info } K B -1 the certificate is a statement by B to any vendor that B will redeem authentic paywords (micropayment tokens) produced by U turned in before the expiration date micropayments

Payment phase:

16 Payment phase commitment when U is about to contact a new vendor, she computes a fresh payword chain w n , w n-1 = h(w n ), w n-2 = h(w n-1 ) = h (2) (w n ), … , w 0 = h (n) (w n ) where n is chosen by the user w n is picked randomly U computes a commitment M = { V, C U , w 0 , date, more_info } K U -1 the commitment authorizes B to pay V for any of the paywords w 1 , …, w n that V redeems with B before the given date note : paywords are vendor specific, they have no value to another vendor micropayments

Payment phase cont’d:

17 Payment phase cont’d payment tokens the i-th payment from U to V consists of the i-th payword and its index (w i , i) when V receives w i , it can verify it by checking that it hashes into w i-1 (received earlier or in the commitment in case of i = 1) since the hash function is one-way (preimage resistant) the next payment w i+1 cannot be computed from w i V needs to store only the last received payword and its index variable size payments can be supported by skipping the appropriate number of paywords let’s assume that the value of each payword is 1 cent and the last payword that U sent is (w k , k) if U wants to perform a payment of 10 cents, then she sends (w k+10 , k+10) micropayments

Redemption phase:

18 Redemption phase at the end of each day, the vendor redeems the paywords for real money at the broker V sends B a redemption message that contains (for each user that contacted V) the commitment and the last received payword w k with its index k B verifies the commitment and checks that iteratively hashing w k k times results in w 0 if satisfied, B pays V k units and charges the account of U with the same amount micropayments


19 Efficiency user U needs to generate one signature per “session” needs to perform one hash computation per payword (hash chains can be pre-computed) needs to store the hash chain and her current position in the chain (time-memory trade-off is possible) vendor V needs to verify one signature per “session” needs to perform one hash computation per payment needs to store only the last received payword with its index, and the commitment broker B needs to verify signatures and compute lot of hashes but all these are done off-line micropayments

PayWord’s problem:

20 PayWord’s problem the vendor cannot aggregate micropayments of different users if the user spent only a few paywords, then the cost of the redemption procedure exceeds the value of the payment e.g., typical value of a payword is 1 cent, whereas processing a credit card transaction costs about 25 cents micropayments

MR1 scheme:

21 MR1 scheme preliminaries check based, the user simply signs the transaction T – encoding of the transaction (IDs of user, merchant, bank, transaction time, value, etc.) F – fixed public function that maps an arbitrary bit string to a number between 0 and 1 s – fixed selection rate of payable checks setup everyone establishes his own public key and corresponding private key for a digital signature scheme the merchants signature scheme must be deterministic payment the user U pays by sending C = (T | Sig U (T)) to the merchant M M verifies if C is payable by checking if F(Sig M (C)) < s micropayments

MR1 scheme cont’d:

22 MR1 scheme cont’d selective deposit M sends only payable checks to the bank for deposit after verification, B credits M’s account with 1/s cents and debits U’s account with the same amount micropayments

Some properties of MR1:

23 Some properties of MR1 Sig M (C) is unpredictable for both U and M practically F(Sig M (C)) is a random number with close to uniform distribution over [0, 1] the probability that F(Sig M (C)) < s is s expected value of a check is 1 cent the bank essentially processes macropayments of value 1/s e.g., if s = 1/1000, then the value is 10$ potential “psychological” problem possibility of user’s excessive payments (in the short term) e.g., it has a positive probability that the first 10 checks sent by the user are all payable value of the goods/service received by the user is 10 cent but her account is debited 100$ in the long run it will work, but users may not tolerate the risk of short term overpaying micropayments

MR2 scheme:

24 MR2 scheme preliminaries and setup same as for MR1 payment U pays by sending C = (T | Sig U (T)) to the merchant M T contains a serial number SN (assigned sequentially to transactions) M verifies if C is payable by checking if F(Sig M (C)) < s selective deposit M sends only payable checks to the bank for deposit maxSN U denotes the highest serial number of a payable check of U processed by B so far if B receives a new payable check, then B credits M’s account with 1/s in addition, if SN > maxSN U , then it debits U’s account with SN-maxSN U and sets maxSN U to SN micropayments

Large scale cheating can be detected:

25 Large scale cheating can be detected cheating is possible the same serial number can be used with different merchants if only one of the two checks is payable than the cheating will not be detected large scale cheating can be detected with statistical auditing example: assume the user uses every serial number twice number of payments made by the user is N highest serial number used is N/2, users is charged at most N/2 cents the joint credit of the merchants is approximately N this can be detected by the bank ! micropayments

Visit Jay Wigdore Site:

Visit Jay Wigdore Site

authorStream Live Help