Experience with American payment systems

    Hello! I am working on an e-commerce startup in the states and recently I managed to work with a number of electronic payment services, namely Stripe , Braintree and Paypal . Today I want to talk a little about what features of electronic payments are in the States, about the practical experience of using the above services and a number of general thoughts on this topic.

    So, at the beginning a little theory. Let's start with what types of payment cards are, because at one time this was a small discovery. So, there are the following types of cards:

    • Debit card  (debit card) - most often we meet them in the form of salary cards
    • Cards with permitted overdraft are almost the same debit cards, but there is a possibility of withdrawing money, let's say "on credit" when your fixed assets are over
    • Credit card
    • Prepaid card (prepaid card) - prepaid card used for payments for goods or services within the prepaid amount. About them a little more will be lower.
    • Local cards - local (national) payment system card
    • International cards - Visa (Visa Electron, Visa Classic, Visa Gold, Visa Platinum), MasterCard (Cirrus, Maestro, MasterCard Standard, MasterCard Gold, MasterCard Platinum), Diners Club, American Express, JCB and China Unionpay.
    • Virtual card - bank prepaid card without tangible media


    So, about prepaid cards. In the States, they are very popular and you can buy them at any Walmart, T-Mobile or other major store. How is it used. Suppose you have a favorite nephew and you decide to give him money for his birthday. But since it is not fashionable to give a cache, and the tribe is buying something, say on the Amazon, then you go and buy such a card, for example, for $ 50. After that, her nephew activates her on the Internet and is ready, he has a $ 50 card. There is also a subspecies of prepaid card that can be replenished. The bottom line is that these cards are popular in the US because they allow you not to shine your personal card on the Internet. What a plus. However, from the point of view of a company that, for example, does not withdraw the entire amount for a service immediately (charge upfront), this is a big risk, because you can never show anything on such a card if you can’t withdraw money. More precisely you can, and there are even special procedures for this, but sometimes it just is not worth it. You can understand what type of card you are working with using the first 6 digits of the card (bin number) and thisservice . By the way, the link has a good infographic about what the number on payment cards means.



    The second wonderful thing that you will definitely encounter when you start working with any payment systems is an error message. More precisely with their description. Why? Because most banks do not have a clear specification of what this or that code means, and when the service receives an error and cannot recognize it, you will see “Payment was declined,” which is actually bad not for you, but for your user, who will be surprised and actively continue to press the “Place order” button, nothing will work, he will be offended and will leave forever. Although he may not have corny money on the card. You need to be prepared for this and give a more detailed description of the error.

    Now a little about payment services, more precisely, what functionality a good payment service should have.

    General requirements:
    • Clear policy use so that you don’t suddenly get disconnected, as Braintree did once with us (who cares - I can tell you in person);
    • Simple and understandable dashboard so that not only programmers, but also customer service can use it;
    • The most transparent documentation for the connection, and the following points should clearly be spelled out in it:
      • Getting started
      • API Docs
      • Testing
      • Two sites - test / production
      • Troubleshooting
      • Work with widgets (if any)

    • Adequate support.


    Functional requirements:
    • Work with users, their maps and additional data;
    • Data validation;
    • Making payments;
    • Subscription;
    • Discount coupons
    • Work with invoices;
    • Accounting.

    It goes without saying that all this should have an understandable REST API, which can be taken and used without additional gestures. An example of additional movements - there is such a service stamps.com that allows you to integrate with all sorts of USPS, FedEx and other services. To access their API, you need to send a request where to include the IP of all developers so that these IPs are added to whitelist. Then wait 2-3 days and there will be happiness. Enterprise is such an enterprise.

    Actually, the time has come to compare the services that I listed at the beginning. We will not go far, Stripe wins, which we actively use. Causes:
    • the most understandable documentation that I have ever read - I have never googled anything additionally;
    • just connect - almost copy-paste from the same documentation;
    • very responsive support, and indeed an example of a company that values ​​customers (if interested, I can tell you in person);
    • the most simple interface of your personal account - intuitively, what is where.

    The same braintree loses due to the fact that it is impossible to connect it without a bottle, and I am silent about their documentation. As an example, try to find the card numbers for testing in the sandbox, good luck.

    About paypal. Paypal is good when you sell electronic goods or a service. In other cases, forget about it. Why? Here is a simple picture of how to integrate with it:



    By the way, Paypal bought Braintree not so long ago and now gives them all sorts of new things for development, because "they are a startup and can do it quickly and efficiently."

    How to connect Stripe. Step one is javascript:
    //Инициируем библиотеку
    Stripe.setPublishableKey('{stripe.publish_key}');
    //Вместо отправки форму получаем от Stripe токен, который в себе содержит зашифрованную информацию
    //после чего передаем ее в собственный обработчик stripeResponseHandler
    Stripe.card.createToken({
    number: $('#cardnumber').val(),
    cvc: $('#cvc').val(),
    exp_month: $('#expdate_mm').val(),
    exp_year: $('#expdate_yy').val(),
    name: $("#cardholdername").val(),
    address_line1: $("#street1").val()),
    address_line2: $("#street2").val(),
    address_city: $("#city").val(),
    address_state: $("#region_id").val(),
    address_zip: $("#postcode").val(),
    address_country: 'US'
    }, stripeResponseHandler);
    //Вписываем в обработчик нужную логику
    var stripeResponseHandler = function (status, response) {
    var $form = $('#payment-form');
    if (response.error) {
    //обрабатываем ошибку от Stripe, например, что введен не тот год/месяц
    } else {
    $.post(url, $form.serialize(), function (data) {
    //отправляем форму к себе на сервер
    });
    

    Now the server code is left - grails / java

     
    //Регистрируемся
    Stripe.apiKey = stripe.secret_key
    //Создаем покупателя
    Map customerParams = new HashMap()
    customerParams.put("email",email)
    customer = Customer.create(customerParams)
    //Заводим ему карту на основании токена, который получили ранее
    Map cardParams = new HashMap()
    cardParams.put("card", token)
    customer.createCard(cardParams)
    //Проводим платеж
    Map chargeParams = new HashMap()
    chargeParams.put("amount", amount)
    chargeParams.put("currency", "usd")
    chargeParams.put("description", "Charge")
    chargeParams.put("customer", customer.id)
    chargeParams.put("card", card.id)
    Charge.create(chargeParams)
    


    Actually everything, you made a payment. The same code, for example on Braintree, will be 2.5 times longer.

    That’s probably all. Ask questions in the comments, the topic is interesting, and I collected enough rake in it.

    Also popular now: