1 / 64

Web Design Workshop DIG4104c

Web Design Workshop DIG4104c. Lecture 7: Payment Systems J. Michael Moshell University of Central Florida. image:myciba.com. Tell ‘ em what you ’ re gonna tell ‘ em. * The Financial System: Who does What * Credit Card Processing: Basic Terms and Concepts

ailis
Télécharger la présentation

Web Design Workshop DIG4104c

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Design Workshop DIG4104c Lecture 7: Payment Systems J. Michael Moshell University of Central Florida image:myciba.com

  2. Tell ‘em what you’re gonna tell ‘em. • * The Financial System: Who does What • * Credit Card Processing: Basic Terms and Concepts • Costs and Risks and Mitigating Risk • Credit Card Fraud • Payment Gateways and APIs • A Gateway Simulator • Foreign Currencies • Square and other non-merchant-account systems • ACH (check processing) • Bitcoin • And – NOT this week – PCI Security Issues -

  3. The Financial System: Cash Transactions $ Merchant Customer Goods & services

  4. The Financial System: Credit Transactions Merchant Customer Goods & services credit info mysterious process Customer's Bank Merchant's Bank $$

  5. Some basic terminology: Merchant Customer Goods & services credit info mysterious process Issuing Bank Merchant's Bank $$

  6. Some basic terminology: Merchant Customer Goods & services credit info mysterious process Issuing Bank Acquiring Bank $$

  7. Card-Present Transactions: Point-Of-Sale (POS) Terminals Merchant Customer Goods & services credit info Issuing Bank Acquiring Bank $$

  8. Card-Not-Present Transactions: E-Commerce Gateways Merchant Customer Goods & services credit info Gateway Software Issuing Bank Acquiring Bank $$

  9. Card-Not-Present Transactions: E-Commerce Gateways Merchant Customer Goods & services credit info Gateway Software Issuing Bank Acquiring Bank $$ An Interactive Explanation is at: http://www.authorize.net/resources/howitworksdiagram/

  10. Terms to Know from that Diagram: http://www.authorize.net/resources/howitworksdiagram/ Issuing Bank (has buyer's account) Acquiring Bank (has merchant's account)

  11. Terms to Know from that Diagram: http://www.authorize.net/resources/howitworksdiagram/ Issuing Bank Acquiring Bank Processor (works for merchant bank) Interchange (Visa/MC; AmEx; Discover; etc)

  12. Acquiring a Merchant Account: How do you get a merchant account? * Based on your (or someone's) credit rating * Bank will require proof of business (e. g. incorporation) and capitalization (i. e. how much reserve money do you have? what is its source?) * Why? Isn't it "all positive" for the bank? Let's look at the process.

  13. The Flow of Money in Credit Card Transactions $74.00 purchase, e. g. of a restaurant meal. Merchant submits charge to gateway. The POS terminal requests authorization of the charge at ($74.00* 1.25)= $92.50 (to allow for possible tip) Issuing bank says "OK they're good for that much". Owner specifies $12.00 tip, signs the card. Î visualphotos.com

  14. The Flow of Money in Credit Card Transactions $74.00 + $12.00 is submitted for capture. Merchant bank asks issuing bank to commit $86.00 and issuing bank agrees. (But no money moves yet.) At settlement (usually once a day), $86.00 is withdrawn from cardholder's account. $86 $82.77 $84.71 $84.46 Seller's account Buyer's account $1.29 $.25 $1.69 Merchant Bank Issuing Bank Gateway visualphotos.com

  15. Discount fees ... Vary greatly (e. g. 1% to 5%) depending on -- - type of card (debit vs. credit, personal vs. corporate) - type of transaction (card-present versus card-not-present) - type of merchandise or service - how good a negotiator the merchant is. Example: Sam's Club has a very good deal with AmEx (Most merchants pay higher fees for AmEx) 7-11 has a very good deal with all CC companies.

  16. The Dreaded CHARGEBACK But ... why did the merchant bank want to know about your credit history and business capitalization? Say I'm the restaurant owner. I take that $82.77 and pay my workers and suppliers. Two weeks later the REAL owner of the credit card finds a strange charge on his statement: "$86.00 at the Platypus Steakburger? Never seen it!" - Contacts his Visa bank and disputes the charges.

  17. The Chargeback Process $86.00is re-credited to the Buyer's account, while the issue is investigated by issuing bank. Possible causes for chargeback: technical (non-sufficient funds...) clerical (duplicate billing, wrong amount ...) quality (lousy merchandise, not received ...) fraud (stolen card; or fraudulent chargeback ...) $86 $121 Seller's account Buyer's account $25.00 penalty Issuing Bank visualphotos.com

  18. The Chargeback Adjudication The Issuing Bank investigates, and may (unusually) side with the merchant. Almost always (80% of time) they side with the buyer. Merchants with >1% total cash flow in chargebacks usually lose their merchant accounts. Why so tough on merchants? Because it's buyers who will cancel a credit card if they aren't happy with it. Merchants have no choice ... they gotta accept credit cards.

  19. The Chargeback Adjudication How to minimize chargebacks? 1) Provide good customer service (e. g. a real, working phone number!) 2) Address Verification System (AVS) AVS is an option in the Gateway Control Panel. If AVS is on, the gateway checks: *numeric part of address (e. g. 123 Smith Street)\ * zipcode, either part or all (e. g. 32816-0494)

  20. Problems with AVS 1) Not all issuing banks support AVS (they will decline charges from gateways requiring AVS information) 2) International banks usually do NOT support AVS (so businesses with many overseas clients almost never use AVS) 3) Even with AVS using North American banks, false declines are common. * User's address is not the business address * User is in a field office but ccard is from HQ addr. * etc.

  21. Debit Cards 1) As a consumer, you should know that - your chargeback rights are drastically less with debit cards, than with credit cards. - if someone steals your debit card and wipes out your account, your bank MAY or MAY NOT reimburse you. Not nearly as good as credit cards. 2) As a merchant, your acquiring bank may or may not be happy to accept debit cards for card-not-present transactions (e-commerce.)

  22. CURL • When a PHP program needs to • invoke another Internet site • Client URL Library supports • http, https • ftp, gopher, telnet, dict, file, ldap • proxies, cookies, user-password authentication

  23. The Technology of Credit Processing • Gateway APIs: We use two of them • - authorize.net – friendly and ubiquitous • - payflopro – belongs to Paypal, notorious • for mediocre (or worse) customer service • Why use both? Because we are using our • conference's merchant accounts (most of • the time)

  24. The Technology of Credit Processing • We have our own merchant account and use it • with Authorize.net gateway ... but its use • exposes us to chargeback risk. • So we use it only for small conferences without • their own Associations' merchant accounts • AND we hold ALL their money until after • the conference.

  25. Guarding Your Wallet • ... AND we hold ALL their money until after • the conference. • Why? If a conference doesn't happen (e. g. • 9/11 interrupts all air traffic), the registrants • want their money back. • But if we gave it to the conference and they • spent it .... we're stuck.

  26. Authorize.Net Advantage: Simple, reliable Good customer support Disadvantage: No Merchant Account (You must get that from a bank or from an authorized reseller)

  27. Authorize.Net Several levels of complexity: http://www.authorize.net/solutions/merchantsolutions/ onlinemerchantaccount/#_how_to_set_up 1. Buy Now Buttons (drop into your website) 2. Certified Third-Party Shopping Cart Systems 3. Advanced Integration Method (AIM) – a full API

  28. CURL in action with AIM Server1 e-merchant server Server2 ccard gateway Browser Access a URL to run PHP program Program sends an https message via CURL gateway talks to cc network

  29. CURL in action Server1 e-merchant server Server2 ccard gateway Browser Access a URL to run PHP program Program sends an https message via CURL gateway talks to cc network network accepts or declines the transaction

  30. CURL in action Server1 e-merchant server Server2 ccard gateway Browser Access a URL to run PHP program Program sends an https message via CURL gateway talks to cc network network accepts or declines the transaction CURL sends reply to calling program Program creates html to notify customer of success or failure

  31. The Mogate simulator Server1 mogatest.php Server2 mogate.php Browser Access a URL to run PHP program Program sends an http message via CURL

  32. The Mogate simulator Server1 mogatest.php Server2 mogate.php Browser simulator pretends to be cc network, accepts or declines the transaction Access a URL to run PHP program Program sends an http message via CURL

  33. The Mogate simulator Server1 mogatest.php Server2 mogate.php Browser simulator pretends to be cc network, accepts or declines the transaction Access a URL to run PHP program Program sends an http message via CURL CURL sends reply to calling program Program creates html to notify customer of success or failure

  34. The Mogate simulator Review the code at mogatest.txt

  35. Separating authorization and capture Sometimes we need to split charges across several merchant accounts, as a conference has several sponsors.

  36. Separating authorization and capture The problem: we wanted to ACCEPT ALL or DECLINE ALL (too many cases to handle, otherwise) Authorize.1 Authorize.2 .... Authorize.n

  37. Separating authorization and capture The problem: we wanted to ACCEPT ALL or DECLINE ALL (too many cases to handle, otherwise) any fail to authorize? Void.1 Void.2 .... Void.n Authorize.1 Authorize.2 .... Authorize.n

  38. Separating authorization and capture The problem: we wanted to ACCEPT ALL or DECLINE ALL (too many cases to handle, otherwise) any fail to authorize? Void.1 Void.2 .... Void.n Authorize.1 Authorize.2 .... Authorize.n all authorized? Capture.1 Capture.2 .... Capture.n

  39. The Credit Card Network Another alternative: https://www.paypal.com/ Supports several service levels Paypal Standard Paypal Advanced Paypal Pro (Formerly Verisign Payflopro) Advantage: Merchant Account Included Disadvantage: Lousy customer support

  40. A Closer Look at the Authorize.net Gateway API Before we walk through the code of the 'mogatest.php' example, we need to review the meaning of URLencoding.

  41. URLencoding Sending data as part of a POST or GET requires that only certain characters be used. Space, and most non-alphanumeric are forbidden. function urlencode does the job.

  42. URLencoding Sending data as part of a POST or GET requires that only certain characters be used. Space, and most non-alphanumeric are forbidden. function urlencode does the job. test string looks like this, with 4 symbols /#$* in it.

  43. URLencoding Sending data as part of a POST or GET requires that only certain characters be used. Space, most non-alphanumeric are forbidden. function urlencode does the job. test string looks like this, with 4 symbols /#$* in it. And the URLencoded result looks like this: test+string+looks+like+this%2C+with+4+ symbols+%2F%23%24%2A+in+it.

  44. URLencoding Now walk through mogatest.txt which is actually mogatest.php The response from a successful charge: 1|1|1|This transaction has been approved|334X54|3347768 Broken out: (there can be up to 68 fields; see AIM_guide p.40++) 1: Response code (see AIM_guide, page 48) 1='approved'; all others 'not approved' 1: Response subcode (seldom useful) 1: Reason code (if declined, tells you why) This transaction has been approved (text for response code) 354X54 - approval code 3347768 - transaction ID

  45. URLencoding A declined transaction -- The response from an unsuccessful charge: 2|1|1|This transaction has been declined.|0|3347768 Broken out: (there can be up to 68 fields; see AIM_guide p.40++) 2: Response code (see AIM_guide, page 48) 2='declined'; 3='error'; 4='held for review' 1: Response subcode (seldom useful) 2: Reason code (if declined, tells you why) This transaction has been declined (text for response code) 0 - approval code 3347768 - transaction ID

  46. Authorize.net’s options: AIM – Advanced Integration Method SIM – Simple Integration Method CP – Card Present Integration see authorize.net for a quick tour of these options.

  47. SIM: if you don’t have https (or don't want AIM complexity) Server1 e-merchant server Server2 ccard gateway Browser Access a URL to run PHP program Program sends an http message via CURL

  48. SIM: if you don’t have https Server1 e-merchant server Server2 ccard gateway Browser Access a URL to run PHP program Program sends an http message via CURL gateway sends form via https client returns ccard info

  49. SIM: if you don’t have https Server1 e-merchant server Server2 ccard gateway Browser Access a URL to run PHP program Program sends an http message via CURL gateway sends form via https network accepts or declines the transaction client returns ccard info gateway sends receipt via https client acknowledges

  50. SIM: behind the button and shopping-card models ... Server1 e-merchant server Server2 ccard gateway Browser Access a URL to run PHP program Program sends an http message via CURL gateway sends form via https network accepts or declines the transaction client returns ccard info gateway sends receipt via https client acknowledges CURL sends reply to calling program Program creates html to wrap up transaction

More Related