Share
Behandling av kredittkort er dessverre langt vanskeligere enn vi kanskje håper, som utviklere. Gitt at det er en så vanlig oppgave, er det virkelig nødvendig at vi hopper gjennom utallige hoops (omgitt av ild, selvfølgelig) for det eneste formålet med å behandle en betaling? Merchants? Gateways? SSL? Sikkerhet? Svært raskt kan en tilsynelatende enkel operasjon bli en overveldende forvirrende og, enda viktigere, farlig oppgave. Hver gang du finner deg selv som håndterer en brukers følsomme data, må du være bedre på tærne.
Stripe oversetter en komplisert, forvirrende og farlig operasjon til et enkelt API-anrop. Ville det ikke vært fantastisk hvis det var en tjeneste som gjorde denne prosessen så enkelt som mulig? En tjeneste bygd av utviklere for utviklere. Hva en tanke! Skriv Stripe; ingen kjøpekontoer, ingen gateways. Et API-anrop, sammen med noen sikkerhetsretningslinjer, er alt du trenger for å begynne å godta kredittkortbetalinger i dag.
Mens Stripe ikke er gratis, ber de bare om 2,9% av hver avgift (pluss .30 cent). Det er det. Ingen setup avgifter, lagringsavgifter, skjulte kostnader - ingen av det. Bare 2,9%. Ikke verst!
Solgt? Jeg var også. La oss behandle vår første testbetaling. Selvfølgelig, før du begynner, besøk stripe.com, Opprett en ny konto (gratis), og fyll ut de ulike skjemaene, for eksempel uttalelsesbeskrivelsen og bankinformasjonen din.
Stripes oppmerksomhet til eleganse strekker seg til designavdeling. Lade en bruker krever to kjerne trinn:
Naturligvis er det første trinnet å bygge et betalingsskjema for produktet ditt. Du har to alternativer: Bruk Stripes Sjekk ut script, som automatisk lager skjemaet, validerer brukerens innspill og genererer det unike token for brukerens kredittkortdata. I situasjoner når konfigurasjon og styling er fleksibel, er dette en utmerket rute å ta. Sett inn en skriptkode, sammen med en håndfull egendefinerte HTML5-attributter, og du er ferdig!
Stripe tilbyr en innebygd form som ytterligere fremskynder prosessen med å godta betalinger. Men i de fleste tilfeller vil du trenge full kontroll. Som sådan vil vi i denne artikkelen bruke et egendefinert skjema. I denne delen oppnår vi tre ting:
Et grunnleggende betalingsskjema kan se ut som:
Legg merke til hvordan vi ikke krever mye informasjon for å behandle et kredittkort. Teknisk er den eneste informasjonen som Stripe krever et kredittkortnummer og utløpsdato. Men som en tommelfingerregel, jo mer informasjon du henter fra brukeren, desto bedre. Skulle avgiften bli bestridt, vil denne ekstra informasjonen være nyttig. Eller med andre ord, jo mer informasjon du ber om, desto mer sannsynlig er det at den sanne eieren av kredittkortet plasserer transaksjonen. Nøkkelen er å finne linjen mellom nok og så mye at brukeren ikke plager å fylle ut skjemaet. Minst, be om brukerens navn, e-postadresse, kredittkortnummer, utløpsdato og CVC-nummer.
For å fortsette å bore inn i hodet må du ikke tillate følsomme kredittkortdata å berøre serveren din. Å gjøre det har potensial til å skape en verden av vondt, hvis det utføres feil. I stedet ta den enkle veien: sørg for at inngangs for brukerens kredittkortdata inneholder ikke Navn egenskaper. Ved å utelate denne attributtet, kan dataene ikke bli lagt ut på serveren din.
Vær nøye med de egendefinerte attributter på inngangene, for eksempel data-stripe = "nummer". Stripe tilbyr et plugin, stripe.js, som bistår i prosessen med å samle brukerens angitte data og generere token. Stripe vil søke etter disse attributter og hente sine respektive verdier.
Å gjøre bruk av stripe.js, referer til skriptet i prosjektet ditt, og sett inn publiserbar nøkkel, som vil bli gitt når du registrerer deg med Stripe. Vi bruker også jQuery i denne artikkelen, selv om det absolutt ikke er nødvendig.
Tenker på setPublishableKey som en måte å identifisere nettstedet ditt når du kommuniserer med Stripe. Ved påmelding vil du bli presentert med to forskjellige versjoner av denne nøkkelen for henholdsvis testing og produksjon.
Deretter må vi opprette det unike, enkeltbrukerstoken for brukerens kredittkortdata. Vi kan bruke Stripe objekt, levert av skriptet som vi importerte, til dette formålet. Enda bedre, vi trenger ikke bekymre oss for serialisering av betalingsformularens data; bare passere gjennom skjemaet jQuery-objektet, og Stripe vil håndtere resten.
Accentsconagua
// Event Lyttere $ ('# betalingsformular'). På ('send', generereToken); var generereToken = funksjon (e) var form = $ (dette); // Ikke trykk knappen Kjøp nå mer enn en gang form.find ('knapp'). Prop ('deaktivert', sant); // Opprett token, basert på formobjektet Stripe.create (form, stripeResponseHandler); // Forhindre skjemaet fra å sende e.preventDefault (); ; var stripeResponseHandler = funksjon (status, respons) ; Med denne biten av JavaScript, når betalingsformularen er sendt, vil Stripe forsøke å generere en enkelt brukstoken, ved hjelp av relaterte data fra inngangene som inkluderer stripe- spesifikke egendefinerte attributter. Det andre argumentet til skape Metoden er en tilbakeringing som vil motta token (response.id) fra Stripes server, og fortsett deretter.
Innenfor denne tilbakeringingen er det viktig å bekrefte resultatet (ble all informasjon gitt korrekt), sett inn token i et skjult inngang, og send skjemaet til serveren din. Igjen, merk at kredittkortinformasjonen ikke / vil ikke slå serveren din - bare token og ikke-sensitive data. Dette er viktig, så skriv aksept eller funksjonstester for å bekrefte det.
Ditt tilbakeringing kan se slik ut:
var stripeResponseHandler = funksjon (status, respons) var form = $ ('# betalingsformular'); // Eventuelle feilfeil? hvis (response.error) // Vis brukeren hva de gjorde feil form.find ('. betaling-feil'). tekst (response.error.message); // Gjør det sende klikkbart igjen form.find ('button'). Prop ('deaktivert', falsk); ellers // Ellers er det bra å gå! Send inn skjemaet. // Sett inn det unike token i skjemaet $ ('', ' type ':' skjult ',' navn ':' stripeToken ',' value ': response.id). appendTo (skjema); // Ring den innleverte innleveringsmetoden på skjemaet // for å holde innleveringen fra å bli kansellert form.get (0) .submit (); ; Det er egentlig ganske enkelt! Send inn en AJAX-forespørsel til Stripes API (ved hjelp av deres nyttige JavaScript-plugin), hent det genererte tokenet, sett det inn i skjemaet og legg det til serveren din!
Hvis du følger med på dette tidspunktet, har du lykkes å generere en enkelt brukstegn og sendt inn betalingsformularen. Nå er det på tide å velge språk på ditt server-side for å opprette ladningen fysisk. Husk, i den forrige delen ble det ikke belastet. Vi har bare generert et token som representerte kredittkortdataene.
Stripe tilbyr en rekke server-side biblioteker for registrering av nye kostnader, eller til og med arrangere abonnementer. Sjansene er høye at ditt foretrukne språk er representert (PHP, Ruby, Python, etc.).
På samme måte som forrige del, kan innlevering av en ny kostnad utføres i noen få trinn:
Se Stripes bibliotekside for installasjonsinstruksjoner. Hvis du bruker PHP, som vi vil være i denne artikkelen, anbefales det at du bruker Composer til å laste ned Stripe-pakken.
"krever": "stripe / stripe-php": "dev-master"
Komponist er fremtiden for PHP dependence management, så kom ombord nå, hvis du ikke allerede har det. En grunnleggende Stripe-kostnad kan ha formen av:
// Sett API-nøkkelen Stripe :: setApiKey ("API-KEY"); Prøv Stripe_Charge :: create (['amount' => 2000, // dette er i cent: $ 20 'valuta' => 'usd', 'card' => $ _POST ['stripeToken'], 'description' => Beskriv produktet ditt]]; fangst (Stripe_CardError $ e) // Avvist. Ikke behandle kjøpet. // Gå tilbake, og fortell brukeren å prøve et nytt kort Det er det! API-nøkkelen vil godkjenne deg som en gyldig Stripe-bruker. I likhet med den publiserbare nøkkelen vil Stripe gi deg to forskjellige versjoner av denne nøkkelen: henholdsvis for testing og produksjon.
Vær oppmerksom på at alle kostnader til Stripe skal deklareres i cent (basert på valutaen selvfølgelig). Hvis prisene lagres i databasen som dollar, euro eller pund, vil du kompensere tilsvarende, når du tar betalt.
Hvis ikke noe unntak kastes, kan du være trygg på at avgiften har behandlet seg. Fortsett ved å tilby brukeren sin digitale nedlastning, eller registrer sitt kjøp med systemet ditt.
Tro det eller ikke, Stripes arbeid er ferdig. Det er sikkert mer som du kan gjøre, for eksempel å skape kunder og administrere abonnementer, men når det gjelder å bare behandle en enkelt betaling, er du ferdig! ... Bortsett fra at du ikke er.
Mens, ja, Stripes arbeid er ferdig, er det på den annen side ikke. Uansett hvilken betalingsleverandør som helst, når du jobber med kredittkortinformasjon, bør sikkerheten være en stor bekymring. Vi har allerede tatt de første skrittene, ved å sørge for at kredittkortdataene aldri berører serveren, men det er fortsatt mer å gjøre. Vi må neste sikre brukerens tilkobling til serveren din. Med andre ord, du trenger et SSL-sertifikat. Under ingen omstendigheter bør du hoppe over dette trinnet!
"SSL (Secure Sockets Layer) er standard sikkerhetsteknologi for å etablere en kryptert lenke mellom en webserver og en nettleser. Denne koblingen sikrer at alle data som sendes mellom webserveren og nettleserne forblir private og integrerte. "- info.ssl.com
Når en bruker tilbyr et nettsted deres kredittkortinformasjon, vil de forvente å se https innenfor adressefeltet. Heldigvis er det å kjøpe et SSL-sertifikat langt enklere enn det pleide å være. Faktisk tilbyr de fleste vertene en SSL-tillegg, som gjør hele prosessen til et enkelt klikk. Det samme gjelder for ulike SaaS-alternativer, for eksempel Pagoda Box eller Heroku.
Tips: Når du aktiverer SSL, er det mulig at bilder og eiendeler bryter. For å fikse dette, må du kontrollere at alle nettadresser bruker
https, heller ennhttp. Eller, som en bedre løsning, bruk protokollrelaterte nettadresser.
Med denne teknologien, populært av Paul Irish, hvis den nåværende siden bruker HTTPS, vil aktivet også bli forespurt med HTTPS.
Forutsatt at verten tilbyr et SSL-tillegg med ett klikk, peker du bare på brukeren din til https: // versjon av bestillingssiden, og du er klar til å gå!
Eksemplene i denne artikkelen er enkle og mest prosessuelle. Sjansene er imidlertid høye, at du skal jobbe med et rammeverk som støtter flere miljøer, ruting og testing av anlegg. Bruk følgende tips som en start for å integrere Stripe med ditt valgramme.
Klart vil du ikke bruke ekte kredittkortnumre til å teste betalingsformularene dine! Heldigvis har Stripe allerede tenkt på dette; de inkluderer et antall kredittkortnumre som simulerer bestemte svar, for eksempel en vellykket kostnad, ugyldig nummer, feil CVC-kode og mange flere.
Her er noen kortnumre som du ofte refererer til:
Når du arbeider med Stripe, har du to unike nøkler, som representerer API og publiserbare nøkler. Videre er det test- og produksjonsvarianter for hver av disse. De fleste rammer gir en måte å håndtere flere miljøer på. På denne måten, for utvikling, vil søknaden din korrekt bruke testnøklene, mens en gang implementert, vil produksjonsversjonene bli referert.
Nedenfor er et Laravel-spesifikt prosjekt. Laravel gir et enkelt miljøsystem. Legg til en konfigurasjonsfil i en mappe som tilsvarer miljønavnet, og disse verdiene vil ta forutsetning over standardinnstillingene.
Først setter vi produksjonsnøklene:
'PRODUCTION API KEY', 'publishableKey' => 'PRODUKSJONSPUBLISERINGSNØYKE'];
Og for utvikling overstyrer vi produksjonsnøklene med sine testmodeller:
'TEST API KEY', 'publishableKey' => 'TEST PUBLISHABLE KEY'];
Nå, når applikasjonen krever API-nøkkelen, bruker du Config :: får ( 'stripe.apiKey'), verdien som returneres vil bli bestemt av miljøet. Suksess!
En vanlig feil som begynner utviklere stammer fra å knytte deres applikasjoner til ulike tilbydere, som Stripe. Din søknad bør ikke vare hvilken fakturering leverandør blir brukt. Det er bare opptatt av at man er tilgjengelig. Ved hardkodende referanser til Stripe i klassene dine oppretter du en direkte forbindelse mellom de to - en som sannsynligvis vil være vanskelig å forandre.
Spør deg selv: "Hvis jeg i fremtiden trenger å bytte ut Stripe med en annen leverandør, hvor vanskelig vil det være?" Hint: Alt som er større enn "bare et øyeblikk"Er en kode lukt.
I stedet kodes til et grensesnitt - kanskje BillingProvider eller BillingGateway. På denne måten kan du opprette ulike implementeringer av grensesnittet: en for Stripe, eller en for en annen tjeneste helt, hvis behovet oppstår. Disse ulike implementasjonene vil inneholde den tjenestespesifikke funksjonaliteten. Hvis du på et tidspunkt finner en billigere faktureringsleverandør enn Stripe, bytter ut Stripe-implementeringen av BillingProvider med en ServiceX versjonen vil bare ta et øyeblikk - det vil si når du har opprettet den nye implementeringen som spørrer ServiceX fakturerings-API.
Her er et skjelett for hvordan dette kan se ut:
// Definer grensesnittgrensesnittet BillingProvider public function charge ($ creditInfo); // Opprett en Stripe-implementeringsklasse StripeBilling public function charge ($ creditInfo) // Stripe_Charge :: charge (...); // Opprett en ServiceX-implementeringsklasse ServiceXBilling offentlig funksjonskostnad ($ creditInfo) // lade bruker med ServiceX
Nå som vi har to implementeringer, kan vi referere til vår nåværende foretrukne faktureringstjeneste, ved hjelp av avhengighetsinjeksjon.
klasse PaymentController beskyttet $ fakturering; offentlig funksjon __construct (BillingProvider $ fakturering) $ this-> fakturering = $ fakturering;
Med denne utviklingsstilen trenger du ikke å røre kontrolleren om du trenger å bevege deg bort fra Stripe. Fordi Stripe ikke er hardkodd, vet den ikke forskjellen!
Når du selger digitale varer, spør deg selv: "Hva skal kjøperen gjøre hvis noe går galt på slutten?" Alltid gi noen måte for kjøperen å kontakte deg eller din bedrift. Hva om bekreftelses-e-posten som inneholder en lenke for å laste ned den digitale filen, kommer aldri inn i kjøperens innboks? Hva skal de gjøre?
Et støtteside, eller til og med en enkel e-postadresse på hjemmesiden, bør hjelpe i disse uunngåelige situasjonene.
DigiCert er Stripes anbefalt SSL-sertifikatleverandør. Hvis du må manuelt kjøpe et SSL-sertifikat, er det en rekke tjenester å velge mellom. Basert på tidligere erfaring, kan du forvente å bruke tretti minutter til en time å sette ting opp. Husk at de fleste sertifikater ikke er gratis, og kan variere fra $ 10 til $ 500, avhengig av leverandøren.
The Stripe-teamet anbefaler DigiCert og Namecheap, men hvis du foretrekker det, kan du vurdere en gratis løsning, for eksempel StartSSL.
En hyppig feil skyldes bruk av skjemadata for å inneholde prisen på produktet som blir kjøpt, muligens via en skjult inngang. Fordi en bruker enkelt kan redigere denne innspillets verdi, er det uklokt å avhenge av det. Hent alltid prisen på produktet fra server-siden. Stol aldri på skjemaet for å fortelle deg. En enkel database spørring er det foretrukne alternativet.
Den eiendelen du selger bør aldri være tilgjengelig for publikum, selv om nettadressen etter din mening er lang og forvirrende nok til det punktet at de fleste aldri ville lære det. Dette er en dårlig praksis av flere grunner.
I stedet oppretter du en nedlastinger bord som huser unike innkjøpskoder, sammen med deres assosierte produkt ids. På denne måten, når en URI, for eksempel / Nedlastinger / 23gsfga831g, er forespurt, vil søknaden din:
For å ta ting videre, kan du også håndheve en nedlastingsgrense. Å tillate dette ville bare kreve at a DOWNLOAD_COUNT feltet legges til i kjøp bord. Ved hver forespørsel skal tallet økes med en. Når dette nummeret når din angitte grense, bør nedlastingen ikke lenger oppgis. Dette kan være nyttig i tilfeller når du vil sikre at nedlastingskoblinger ikke deles.
Den fantastiske tingen om Stripe er at den oversetter en komplisert, forvirrende og farlig operasjon til et enkelt, enkelt API-anrop. Ingen selgerkontoer, ingen gateways, ingen skjulte avgifter. Det er en grunn til at de sier at Stripe er latterlig enkel å bruke. Det er!
