PhpSpreadsheet is a library written in pure PHP providing a set of classes that allow to read from and to write to different spreadsheet file formats, like Excel and LibreOffice Calc. Let’s see how to use it with a Symfony app.

Prerequisites

First, we need PHP version 5.6 or newer and ensure that PHP extensions php_zip, php_xml and php_gd2 are enabled before developing using PhpSpreadsheet.

Then use composer to install PhpSpreadsheet into our project:

composer require phpoffice/phpspreadsheet 1.0.0

How to create a basic spreadsheet?

In this first part, we will see how to create a spreadsheet showing characteristics of some browsers (name, developer, release date and programming language used).

Spreadsheet creation

First we must create a workbook using the Spreadsheet class. Once we have a single worksheet, it is time to write some data. The main advantage of PhpSpreadsheet is that all parts of our code is easy to understand even by a non-developer as it describes simple actions that are usually done by a user writing in spreadsheet applications. Thus, we will construct our spreadsheet accessing cells and settings values.

use PhpOffice\PhpSpreadsheet\Spreadsheet;

protected function createSpreadsheet()
{
    $spreadsheet = new Spreadsheet();
    // Get active sheet - it is also possible to retrieve a specific sheet
    $sheet = $spreadsheet->getActiveSheet();

    // Set cell name and merge cells
    $sheet->setCellValue('A1', 'Browser characteristics')->mergeCells('A1:D1');

    // Set column names
    $columnNames = [
        'Browser',
        'Developper',
        'Release date',
        'Written in',
    ];
    $columnLetter = 'A';
    foreach ($columnNames as $columnName) {
        // Allow to access AA column if needed and more
        $columnLetter++;
        $sheet->setCellValue($columnLetter.'2', $columnName);
    }

    // Add data for each column
    $columnValues = [
        ['Google Chrome', 'Google Inc.', 'September 2, 2008', 'C++'],
        ['Firefox', 'Mozilla Foundation', 'September 23, 2002', 'C++, JavaScript, C, HTML, Rust'],
        ['Microsoft Edge', 'Microsoft', 'July 29, 2015', 'C++'],
        ['Safari', 'Apple', 'January 7, 2003', 'C++, Objective-C'],
        ['Opera', 'Opera Software', '1994', 'C++'],
        ['Maxthon', 'Maxthon International Ltd', 'July 23, 2007', 'C++'],
        ['Flock', 'Flock Inc.', '2005', 'C++, XML, XBL, JavaScript'],
    ];

    $i = 3; // Beginning row for active sheet
    foreach ($columnValues as $columnValue) {
        $columnLetter = 'A';
        foreach ($columnValue as $value) {
            $columnLetter++
            $sheet->setCellValue($columnLetter.$i, $value);
        }
        $i++;
    }

    return $spreadsheet;
}

Formatting

PhpSpreadsheet also provides a way to set style to our spreadsheet thanks to several classes gathered in the \PhpSpreadsheet\Style folder. The following code shows basic methods that can be used to center text, change font weight and autosize column.

use PhpOffice\PhpSpreadsheet\Style\Alignment;

$columnLetter = 'A';
foreach ($columnNames as $columnName) {
    // Center text
    $sheet->getStyle($columnLetter.'1')->getAlignment()->setHorizontal(Alignment::HORIZONTAL_CENTER);
    $sheet->getStyle($columnLetter.'2')->getAlignment()->setHorizontal(Alignment::HORIZONTAL_CENTER);
    // Text in bold
    $sheet->getStyle($columnLetter.'1')->getFont()->setBold(true);
    $sheet->getStyle($columnLetter.'2')->getFont()->setBold(true);
    // Autosize column
    $sheet->getColumnDimension($columnLetter)->setAutoSize(true);
    $columnLetter++;
}

Managing file formats and save spreadsheet

Now, we have our spreadsheet correctly set but we still want to use it in spreadsheet applications. Supported file formats are listed here. We will then have to choose a format to write our spreadsheet into a file.

To easily choose between famous spreadsheet formats, we will create a simple form like this:

use Symfony\Component\Form\AbstractType;
use Symfony\Component\Form\Extension\Core\Type\ChoiceType;
use Symfony\Component\Form\FormBuilderInterface;

public function buildForm(FormBuilderInterface $builder, array $options)
{
    $builder
        ->add('format', ChoiceType::class, [
            'choices' => [
                'xlsx' => 'xlsx',
                'ods' => 'ods',
                'csv' => 'csv',
            ],
            'label' => false,
            'placeholder' => 'Select a format',
        ])
    ;
}

We can use this form in our controller to create correct file according to a given format and then stream the response back to the client.

use AppBundle\Form\Type\ExcelFormatType;
use PhpOffice\PhpSpreadsheet\Writer\Csv;
use PhpOffice\PhpSpreadsheet\Writer\Ods;
use PhpOffice\PhpSpreadsheet\Writer\Xlsx;
use Symfony\Component\HttpFoundation\StreamedResponse;

/**
 * @Route("/export", name="export")
 */
public function exportAction(Request $request)
{
    $form = $this->createForm(ExcelFormatType::class);
    $form->handleRequest($request);
    if ($form->isSubmitted() && $form->isValid()) {
        $data = $form->getData();
        $format = $data['format'];
        $filename = 'Browser_characteristics.'.$format;

        $spreadsheet = $this->createSpreadsheet();

        switch ($format) {
            case 'ods':
                $contentType = 'application/vnd.oasis.opendocument.spreadsheet';
                $writer = new Ods($spreadsheet);
                break;
            case 'xlsx':
                $contentType = 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet';
                $writer = new Xlsx($spreadsheet);
                break;
            case 'csv':
                $contentType = 'text/csv';
                $writer = new Csv($spreadsheet);
                break;
            default:
                return $this->render('AppBundle::export.html.twig', [
                    'form' => $form->createView(),
                ]);
        }

        $response = new StreamedResponse();
        $response->headers->set('Content-Type', $contentType);
        $response->headers->set('Content-Disposition', 'attachment;filename="'.$filename.'"');
        $response->setPrivate();
        $response->headers->addCacheControlDirective('no-cache', true);
        $response->headers->addCacheControlDirective('must-revalidate', true);
        $response->setCallback(function() use ($writer) {
            $writer->save('php://output');
        });

        return $response;
    }

    return $this->render('AppBundle::export.html.twig', [
        'form' => $form->createView(),
    ]);
}

How to retrieve data from a spreadsheet?

Once we are able to create spreadsheets, we also need to know how to read from existing ones. In this second part, we will see how to retrieve data from the spreadsheet we have just created.

Loader or Reader

To load a workbook, it is possible to simply use static load() method of the \PhpOffice\PhpSpreadsheet\IOFactory class. This method will attempt to identify the file type and instantiate the corresponding loader in order to load the file.

use PhpOffice\PhpSpreadsheet\IOFactory;

protected function loadFile($filename)
{
    return IOFactory::load($filename);
}

If we do not want to be able to manage all supported file types or if we want to add some specific logic, we can instantiate a specific reader object for our file and use the reader’s load() method to correctly read the file.

Moreover, if we are not sure of the file type, it is possible to use the IO Factory’s identifiy() method combined with createReader() method to identify and instantiate the reader object we need.

use PhpOffice\PhpSpreadsheet\Reader\Csv as ReaderCsv;
use PhpOffice\PhpSpreadsheet\Reader\Ods as ReaderOds;
use PhpOffice\PhpSpreadsheet\Reader\Xlsx as ReaderXlsx;

protected function readFile($filename)
{
    $extension = pathinfo($filename, PATHINFO_EXTENSION);
    switch ($extension) {
        case 'ods':
            $reader = new ReaderOds();
            break;
        case 'xlsx':
            $reader = new ReaderXlsx();
            break;
        case 'csv':
            $reader = new ReaderCsv();
            break;
        default:
            throw new \Exception('Invalid extension');
    }
    $reader->setReadDataOnly(true);
    return $reader->load($filename);
}

Retrieve data

Now that we have a spreadsheet, we can iterate through each worksheet it contains to construct an array containing browser characteristics.

protected function createDataFromSpreadsheet($spreadsheet)
{
    $data = [];
    foreach ($spreadsheet->getWorksheetIterator() as $worksheet) {
        $worksheetTitle = $worksheet->getTitle();
        $data[$worksheetTitle] = [
            'columnNames' => [],
            'columnValues' => [],
        ];
        foreach ($worksheet->getRowIterator() as $row) {
            $rowIndex = $row->getRowIndex();
            if ($rowIndex > 2) {
                $data[$worksheetTitle]['columnValues'][$rowIndex] = [];
            }
            $cellIterator = $row->getCellIterator();
            $cellIterator->setIterateOnlyExistingCells(false); // Loop over all cells, even if it is not set
            foreach ($cellIterator as $cell) {
                if ($rowIndex === 2) {
                    $data[$worksheetTitle]['columnNames'][] = $cell->getCalculatedValue();
                }
                if ($rowIndex > 2) {
                    $data[$worksheetTitle]['columnValues'][$rowIndex][] = $cell->getCalculatedValue();
                }
            }
        }
    }

    return $data;
}

Displaying data

Let’s assume that our spreadsheets are all located in a folder named export and that we want to retrieve data from a specific spreadsheet named Browser_characteristics.xlsx.

By combining the two previous parts, we can display our data with a basic Twig template.

/**
 * @Route("/import", name="import")
 */
public function importAction(Request $request)
{
    $filename = $this->get('kernel')->getRootDir().'/../export/Browser_characteristics.xlsx';
    if (!file_exists($filename)) {
        throw new \Exception('File does not exist');
    }

    $spreadsheet = $this->readFile($filename);
    $data = $this->createDataFromSpreadsheet($spreadsheet);

    return $this->render('AppBundle::import.html.twig', [
        'data' => $data,
    ]);
}

Conclusion

With this article, you are now able to correctly manage PhpSpreadsheet basic usages. If you need an example of this test case, we got a github repository to help you test that!

If you have other questions related to PhpSpreadsheet, don’t hesitate to comment down below, and we’ll try our best to answer quickly and if you are interested in other articles about PhpSpreadsheet be sure to tell us!

Managing spreadsheets with Symfony was originally published in theTribe on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here we will go over the following subjects:

• Subscriptions/recurring payments
• Lifecycle of subscriptions
• Coupons
• SEPA payments

Prerequisites

Prerequisites are the same as for the previous post. You need a configured stripe account and once it’s done you will need your api keys.

Subscriptions

Subscription workflow

First thing to know: a subscription is a recurring payment handled by Stripe. This means that Stripe needs to know about your customer and a valid payment method. To detail the process, here is what you should do:

• Create a Stripe Customer
• Create a Stripe Source (payment method)
• Create a Stripe Subscription

Customer creation

If for some reason you already created a Stripe Customer and/or Source it is a best practice to reuse it by fetching it using the cus_id/src_id provided by Stripe at the creation time.

A bit of node.js code for a getOrCreateStripeCustomer function using the stripe npm package:

import stripePackage from 'stripe';

   const stripe = stripePackage(process.env.STRIPE_SECRET_KEY);

    const getOrCreateStripeCustomer = async (user) => {
    let customer;
    const customerId = user.stripeCustomerId;
    if (customerId) {
        customer = await stripe.customers.retrieve(customerId);
    } else {
        customer = await stripe.customers.create({
            email: user.email,
        });
        await user.update({ stripeCustomerId: customer.id });
    }

    return customer;
};

In this piece of code, user represent the user in my application and it has a stripeCustomerId attribute. It is also worth noting that my STRIPE_SECRET_KEY is pushed into the environment but you can manage this part however you like. It is important to mention that the key is secret and should not appear in any commit or public file.

Source creation

Now that we have a method to create a customer we must attach a source to this customer. The source creation usually happens in the frontend with Stripe. It’s a best practice to keep it that way so that no sensible information goes through your servers, it reduces the risk of having your clients banking data stolen and let Stripe handle all the risky data. In our case we were in a ReactJS environment so we used the react-stripe-elements package. We also included the iban package to check that provided IBAN numbers for SEPA payments are valid.

The payment UI looks like this:

import IBAN from 'iban';
import { flowRight } from 'lodash/fp';
import PropTypes from 'prop-types';
import React from 'react';
import { reduxForm, formValues } from 'redux-form';
import { CardElement, injectStripe } from 'react-stripe-elements';

const PaymentForm = ({
    stripe, paymentMedium, iban, owner,
}) => {
    const stripeSourceCreation = async (event) => {
        event.preventDefault();
        let source;
        if ('card' === paymentMedium) {
            // Stripe Elements magic gets the only card elements available and create the source
            source = await stripe.createSource();
        } else {
            source = await stripe.createSource({
                type: 'sepa_debit',
                sepa_debit: { iban },
                currency: 'eur',
                owner,
            });
        }
        if (source) {
            const postBody = {
                stripeSourceId: source.source.id,
                paymentMedium,
            };
            // Here you POST the above body to link source to customer in the backend (see below)
        }
    };

const checkIBAN = (event) => {
        const { target } = event;
        target.classList.remove('valid');
        target.classList.remove('invalid');
        if (IBAN.isValid(iban)) {
            target.classList.add('valid');
        } else {
            target.classList.add('invalid');
        }
    };

return (
        <form onSubmit={stripeSourceCreation}>
            <p>Payment by { 'card' === paymentMedium ? 'card' : 'SEPA' }</p>
            { 'card' === paymentMedium ? (
                <CardElement />
            ) : (
                <Fragment>
                    <span>IBAN Number:</span>
                    <input
                        placeholder="ex: FR68539007547034"
                        onBlur={checkIBAN}
                        name="iban"
                    />
                    <span>Account owner:</span>
                    <input placeholder="ex: Marie Dupont" name="owner" />
                    <p>
                        Here you should include the SEPA Mandate provided by Stripe
                    </p>
                </Fragment>
            )}
        </form>
    );
};

PaymentForm.propTypes = {
    stripe: PropTypes.shape().isRequired,
    paymentMedium: PropTypes.string.isRequired,
    iban: PropTypes.string,
    owner: PropTypes.string,
};

export default flowRight([
    reduxForm({
        form: 'create-stripe-source-form',
        type: 'simulation-form',
    }),
    formValues({
        iban: 'iban',
    }),
    injectStripe,
])(PaymentForm);

Once created in the frontend you should get the sourceId returned by stripe and link it to your client (this you probably should do in your backend). It’s a simple Stripe API call:

stripe.customers.createSource(stripeCustomerId, { source: stripeSourceId });

Finally you can create the subscription. The first step for this happens in the Stripe dashboard where you must create your “plans”. Go to the Billing > Products page and create you product and then inside the product, create your pricing plan. When creating the plan you set an ID which you will use in your subscription code:

const subscription = await stripe.subscriptions.create({
    customer: stripeCustomerId,
    items: [{ plan: stripeSubscriptionPlanId }],
});
// then update you user to save the fact that the plan is activated!

And now your subscription is in place, it will keep running until further notice. Every month (or whatever billing interval you choose) the customer will be charged with the subscription amount on the payment source you registered. Unless there is a payment failure… This is where webhooks arrive on scene.

Webhooks and subscriptions lifecycle

Webhooks allow Stripe to proactively warn you about events occurring in Stripe operations. It can be a payment failure, a revoked source, a deleted customer… All of these events you can be notified about (there is more than seventy different events, we will only talk about one as an example but they all work the same way).

First you must go in your Stripe dashboard, in the “Developers” section and “Webhooks” subsection. Click on the “+ Add endpoint” button and set your endpoint URL. You can decide to send all events to the endpoint or just a subset. Finally you must save the “Signing secret” to check for legitimate requests on your endpoint. Once this is done you have to create your endpoint. I let you choose your preferred way to handle it, just be careful to match the URL you put in the Stripe interface and to listen for the POST method.

In your endpoint you will need to do the following actions:

• Identify the legitimacy of the request
• Extract Stripe data
• Do things in reaction to the event

The first two points are easy as pie. Given you are using express, here is the sample to extract data and validate request:

import stripePackage from 'stripe';

const { body, header } = req; // req is your express request object
const stripe = stripePackage(process.env.STRIPE_SECRET_KEY);
const webhookSecret = process.env.STRIPE_WEBHOOK_SECRET;
const stripeEvent = stripe.webhooks.constructEvent(body, headers['stripe-signature'], webhookSecret);

And here you are, with the data sent by stripe webhooks!

Last step consists in doing things depending on the event type and/or content and this is totally up to you and the specificities of your processes. I just give you the link to the documentation describing the events.

While coding your webhooks you should keep in mind that a best pratice is to send a status 200 response to Stripe ensuring them you got the message before doing any heavy lifting.

Coupons management

Once your subscriptions are in place, you may want to add some coupon system to handle marketing operations, special events, or angry users.

First thing to know, Stripe coupons can be used for subscriptions only. No coupons for one time payments. If you want to do that, you are doomed to make the system in-house. Stripe sends you to a recipe to do it in rails but anyway you have to engineer that piece. It means manage a full CRUD for coupons and applying them on payment before interacting with Stripe.

If you are going for a standard subscription only coupons, you can manage those directly in the Stripe dashboard in the Billing > Coupons menu. Same as for subscriptions, you will set an ID for the coupon (which is the one users should enter when paying to get reductions). This ID entered by users you only have to push it to Stripe alongside the subscriptions like this:

await stripe.subscriptions.create({
    customer: stripeCustomerId,
    items: [{ plan: stripeSubscriptionPlanId }],
    coupon: couponID,
});

This way the coupon will be applied on the subscription. You can also update an existing subscription to apply a coupon on it.

Last detail, if you need to create coupons on the fly, it’s possible using the Coupon API. An example is available in the Stripe doc about discounts.

Finally, for Europeans it’s common to use SEPA payments. Let’s dig into that!

Easy setup for SEPA… or not

SEPA (Single Euro Payments Area) is a mean to pay in some places in Europe. It has some drawbacks (which you will learn below) and also a processing workflow which is a bit more complicated than cards. The main reason being that SEPA needs to be accepted on the client side, and it can take up to 14 days. This asynchronous process adds some complexity to the whole thing.

Activate SEPA

To setup a SEPA payment method, all you have to do is prepare to lot of administrative process and a tiny little bit of code. SEPA payment method (named sepa_debit in the Stripe API) is not activated by default. You must go to Stripe website into the “payments → settings” panel and ask for “SEPA Direct Debit” activation. And… wait. SEPA debit can officially be activated only after 30 to 60 days of payments activity on cards. You can try and contact the Stripe team for an early activation and they will warn you about the usage of SEPA which has some drawbacks:

• Users can cancel the payment through SEPA within 8 weeks after the withdrawal without providing any reason. This is considered pure loss by Stripe and you have no way to prevent or defend against this.
• Users can dispute the payment 11 months after the 8 first weeks (this means your cash is secured only 13 months after payment). These disputes are decided at the bank levels, Stripe may ask more information from you. If the bank decides to cancel the payment, your stripe balance will be reduced accordingly and another 7.5 € will be withdrawed (the dispute process fee).
• Any failed payment through SEPA will lead to a 7.5 € fee you will have to pay (for example if your client does not have enough cash on their account)

If after all that you still want to go on, be warned that the Stripe test API will stay closed to all your SEPA related calls until you are activated.

As for the setup, if you went this far, you already have the code to create the source in the UI code in the “Source Creation” section. And the subscription doesn’t really care for the source type, it just charge any source you gave. The real work is in the webhooks since SEPA is prone to more payment failures, but this too is already in your hand. I have nothing more to say, to your keyboards!

Conclusion

So that’s pretty much all you need to know to setup your subscriptions management with Stripe.

If you have other questions related to Stripe, don’t hesitate to comment down below, and we’ll try our best to answer quickly and if you are interested in other articles about Stripe be sure to tell us!

Making a recurring payment with Stripe, manage subscriptions and more was originally published in theTribe on Medium, where people are continuing the conversation by highlighting and responding to this story.

Prerequisites

Be sure to create an account and configure it, you won’t be able to test anything without a Stripe account as you will need your api keys for that.

There are several ways to work with Stripe and achieve a single payment with a credit card, in this article we will tokenize the card details and then charge this card.

Front

Set up the Stripe.js script

First things first, you need to import the Stripe.js library and instantiate the stripe object, which can easily be done with the following code:

<script type="text/javascript" src="https://js.stripe.com/v3/"></script>
<script>
    const stripe = Stripe('pk_test_UseYourPublishableKeyHere');
</script>

Stripe recommends you not only to import the script on the payment pages of your site, but on every page, as it packages an advanced fraud functionality.

Create our payment form

Now that we have prepared the script, we need a form to let the user put his card details. We will use the Elements to create our form, so we can use the following:

<form action="/charge" method="post" id="payment-form">
    <div class="form-row">
        <label for="card-element">
            Credit or debit card
        </label>
        <div id="card-element">
            <!-- a Stripe Element will be inserted here. -->
        </div>

<!-- Used to display Element errors -->
        <div id="card-errors" role="alert"></div>
    </div>

<button>Submit Payment</button>
</form>

For now if you try to display the page, all you have is an empty form without any input. We need to instantiate the Element in our script to fill the form with a Stripe form for the card:

const elements = stripe.elements();
const card = elements.create('card');
card.mount('#card-element');

We will now retrieve a set of inputs allowing the user to fill its card details. Those inputs come with a nice UX and error management so you can concentrate on more important things.

Create the token

Everything is ready, so now let’s get on with the source creation. The first thing to do with our form is to create a token with the payment details. The token creation ensures that you do not pass any sensitive data to your server. Thanks to the card Element, this is easy, all we need to do is to call the method stripe.createToken(card). Add some error management and use the promise sent back to obtain the following:

const form = document.getElementById('payment-form');
form.addEventListener('submit', function(event) {
    event.preventDefault();

    stripe.createToken(card).then(function(result) {
        if (result.error) {
            // Inform the user if there was an error
            const errorElement = document.getElementById('card-errors');
            errorElement.textContent = result.error.message;
        } else {
            // Send the token to your server
            stripeTokenHandler(result.token);
        }
    });
});

Now that we have our token, we need to send it to our server, and we can do it thanks to a hidden input:

function stripeTokenHandler(token) {
    // Insert the token ID into the form so it gets submitted to the server
    const form = document.getElementById('payment-form');
    const hiddenInput = document.createElement('input');
    hiddenInput.setAttribute('type', 'hidden');
    hiddenInput.setAttribute('name', 'stripeToken');
    hiddenInput.setAttribute('value', token.id);
    form.appendChild(hiddenInput);

    // Submit the form
    form.submit();
}

Please note that the Element’s fields are not sent to the server with this code, meaning that you are operating in a PCI compliant way. This way, we can send all the data we had in our form with the token and your server never receives sensitive card details from your request (card number, expiracy date, cvc).

Backend

For the backend we will be using Symfony and Composer to install dependencies. In order to have something reusable later, we will create a service for all our Stripe methods.

Install

To use Stripe in our backend Application, we need to install the stripe-php library. All you need to do is to run the following command:

composer require stripe/stripe-php

Stripe Service

For starters, we need to save our API keys. Let’s add our key in the app/config/parameters.yml file, like so:

stripe_secret_key: sk_test_UseYourSecretKeyHere stripe_publishable_key: pk_test_UseYourPublishableKeyHere

This way, we can specify for each instance the keys to use, test keys for the test instance and the live keys for our production environment.

Now we can create our service. This service will need the secret key to initialize the Stripe library, so it will look like this:

<?php
namespace AppBundle\Services;

use Stripe\Stripe;

class StripeService
{
    public function __construct(string $stripeSecretKey)
    {
        Stripe::setApiKey($stripeSecretKey);
    }
}

And now we can register our service in the app/config/services.yml config file:

AppBundle\Services\StripeService:
    arguments: ['%stripe_secret_key%']
    public: true

Now that we have a functional service for the Stripe library, let’s make our first payment.

Payment Request

Now let’s implement the charge mechanism in our Stripe service:

/**
 * @throws \Stripe\Error\Card
 */
public function charge(string $token)
{
    $charge = \Stripe\Charge::create([
        'amount' => 4200,   // Amount in cents
        'currency' => 'eur',
        'description' => 'Example charge',
        'source' => $token,
    ]);

    return $charge;
}

With this simple code, we can process a payment of 42.00€ (passed in cents to the API), with the card corresponding to the token given. The description is a text that will appear in your Stripe dashboard and on the client bank receipt. Now all we have to do is use this method in our controller :

/**
 * @Route("/charge", name="charge_simple")
 * @Method({"POST"})
 */
public function chargeAction(Request $request)
{
    if (!$request->request->has('stripeToken')) {
        return new BadRequestHttpException('No stripe token to create charge');
    }

    $charge = $this->container
        ->get(StripeService::class)
        ->charge($request->request->get('stripeToken'));

    $amount = $charge->amount / 100; // Amount is in cents

    $this->addFlash(
        'notice',
        "Charge of $amount € successful !"
    );

    return $this->redirectToRoute('homepage');
}

This action is pretty straightforward, we retrieve the token, charge the card, and display a message. Clean and simple.

But what if there is a problem and the card cannot be charged? The charge method of the Stripe library throws an exception that will help you manage those errors, so you can do something like this:

try {
    $charge = $this->get(StripeService::class)->charge($params['stripeToken']);

    $amount = $charge->amount / 100; // Amount is in cents
    $this->addFlash(
        'notice',
        "Charge of $amount € successful !"
    );
} catch (\Stripe\Error\Card $e) {
    $this->addFlash(
        'error',
        $e->getMessage()
    );
}

The message of the exception is readable by your customers (if they are english speakers). If you want to provide internationalization, you can rely on the Stripe error code, that you can get with $e->getStripeCode().

Conclusion

So that’s pretty much all you need to know to process payments with Stripe. The front part is almost done by Stripe itself and the back is easy to use, and everything is secure, so it’s worth a try. If you need an example of this test case, we got a github repository to help you test that!

If you have other questions related to Stripe, don’t hesitate to comment down below, and we’ll try our best to answer quickly and if you are interested in other articles about Stripe be sure to tell us!

Making a simple payment with Stripe (API Version 2017–08–15) was originally published in theTribe on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nous avons vu dans la satisfaction client un moyen de répondre à nos valeurs d’excellence et de progression continue. Mesurer régulièrement la satisfaction client permet d’apporter une réponse rapide et sur-mesure à nos clients dans la relation que nous avons avec lui et sur ce que nous produisons, et ce, sans attendre la fin du projet.

Par quelles étapes sommes-nous passés pour recueillir la satisfaction et agir dessus ?

Ce qui nous semblait important dès le début de theTribe, c’est que la satisfaction des clients devait avoir un impact fort sur notre fonctionnement : on ne parle pas juste de formulaires à remplir, mais des questions qui vont changer positivement leur relation avec nous.

Par ailleurs, dès la création de theTribe, il y a eu une volonté de valoriser le travail des développeurs sur le plan humain mais également au niveau de sa rémunération. La satisfaction client a une influence directe sur les primes.

Choix des questions

La création des questionnaires a été l’étape la plus complexe du projet. L’idée était de sonder les clients en un minimum de questions. Alors même que nous venions de débuter l’aventure theTribe, nous avions déjà pu avoir un premier retour sur ce qui pouvait créer de la frustration chez nos clients :

• Le manque de communication ;
• Un mauvais avancement du projet ;
• Une mauvaise impression sur la qualité technique.

Nous avions ainsi identifié nos questions, celles qui permettraient de pouvoir identifier un mécontentement ou un souci sur un projet, et d’y remédier. Étant continuellement à la quête de l’excellence, nous avons ajouté une question afin de savoir si nous réussissons à surprendre notre client, à créer un effet « Waow » chez lui.

Très vite, nous avons lancé nos questionnaires sur TypeForm et nous les avons transmis une fois par mois à nos clients en expliquant notre démarche. Puis, nous avons intégré la complétion du formulaire lors des rétrospectives de nos cérémonies SCRUM.

Avec les premiers retours, nous avons pu affiner nos formulations afin d’exploiter au mieux le ressenti des clients et diminuer l’effet de déjà-vu de ce genre de questionnaire.

Nous sommes arrivés aux questions suivantes :

• L’avancement est-il conforme à vos attentes ?
• L’équipe à votre service est-elle réactive ?
• Les efforts de la tribu ont-ils dépassé vos attentes ?
• Quel est votre ressenti sur la qualité technique du projet ?
• Avez-vous des questions ou des remarques ?

Cela marchait plutôt bien quand nous avions un nombre de projets simultanés qui se comptait sur les doigts d’une main. L’équipe a grandi, le nombre de projets aussi, et le temps passé à étudier chaque réponse et calculer les notes était de plus en plus long.

La solution était simple : l’automatisation du process !

Diffusion de l’information

Fidèles à nos valeurs, il nous a semblé important que chaque membre de la tribu puisse connaitre l’évolution des autres projets, les problématiques rencontrées et puisse apporter des solutions. Il fallait qu’en plus du calcul automatique des notes, celles-ci soient communiquées à l’ensemble des membres de la tribu.

Nous avons fait le choix de diffuser un maximum d’informations entre les membres de la tribu via Slack, l’ajout des retours de nos clients sur cet outil était la suite logique. En regardant de plus près l’API proposée, nous avions la possibilité d’aller un peu plus loin dans l’affichage en y intégrant nos règles d’intéressement pour les équipes.

Nous avons pour le moment trois possibilités, correspondant aux palliers de primes décidés en équipe, en sachant que la note maximum est 17 :

• Au-dessus ou égal à 13, l’équipe est récompensée pour ses bons résultats ;
• Au-dessus ou égal à 10, l’équipe ne reçoit qu’une faible partie de la récompense ;
• En dessous, aucune récompense n’est possible.

Dans tous les cas, l’équipe devra se remettre en question pour s’améliorer et apporter une plus grande satisfaction (oui, même si elle est déjà optimale).

La diffusion de l’information était faite par un script, qui, en règle générale, était lancé quelques jours avant la fin du mois. Nous obtenons un message par projet, résumant les notes ainsi que le commentaire qui peut y être associé.

Le résultat était satisfaisant et permettait de répondre au besoin que nous avions. A chaque fin de mois, il y avait un réel engouement lors de la découverte des notations effectuées par nos clients. Mais là encore, notre façon de procéder était encore perfectible et plusieurs problèmes se posaient chaque mois :

• L’avancement des notations n’était pas accessible à tout le monde ;
• Il manquait régulièrement des réponses, il y avait plusieurs vagues de message sur Slack ;
• Une seule personne dans l’entreprise était en capacité de déclencher l’export des notes sur Slack.

Le dashboard de la Satisfaction Client

Nous avions besoin d’un tableau de bord nous permettant de voir où en étaient les notations, de modifier la liste des projets et surtout que tout le monde puisse demander à Hodor (notre bot Slack) la publication des notes.

Avec un savant mélange de Boostrap, de Silex et un soupçon de Caféine, nous avons créé une interface simple répondant à ces problématiques.

Tout les membres de la tribu peuvent consulter leur progression et celle des autres, ils peuvent également, s’ils le jugent nécessaire, publier les résultats.

La satisfaction de nos clients fait partie de la qualité de nos projets. Mais, comme tout processus, nous aurons à le maintenir pour correspondre à l’évolution des problématiques que nous rencontrerons afin de toujours nous améliorer.

La satisfaction client chez theTribe was originally published in theTribe on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this month hackathon, we are going to create a Twitter Slack bot to use the Twitter account of theTribe.

Project presentation and motivation

• Hey man, have you seen this tweet? We should answer with the company’s Twitter!
• You’re right, give me just a sec and I’ll do it.
• You’ve got the access?
• No, but I’ll ask the boss…

A few moments later:

That’s the risk when you don’t have a communication department and you rely on people with a special sense of humor. Two problems emerged from this real and not fake at all story:

1) Everyone needs to have the credentials for the Twitter account. This is a bad practice and if someone leaves the company, the password must be changed.

2) We don’t want our beer lover developers to post anything when they have been drinking another good craft beer (social medias and alcohol don’t mix very well).

With this in mind, we decided to create a bot for our Slack team. This way no one needs to have the Twitter account credentials and we can decide all together if we want to publish a message or not. Another advantage of creating a bot is that we can capitalize on the bot we created last time.

Conception

We split up into two groups to work on the main features: the voting system and the tweet post.

Vote system

We agreed on a simple set of rules:

• People will vote by adding a 👍 or 👎 reaction on the suggested message
• The bot will automatically add both reactions to the message to gain time (we don’t want to open the emoji modal everytime)
• The message is posted if there are 5 more 👍 than 👎

The bot needs to be aware of the reactions posted on the messages so we are using the two following events.

start() {   
  super.start()
  ...   
  this.rtm.on(RTM_EVENTS.REACTION_ADDED,this.handleReaction)
  this.rtm.on(RTM_EVENTS.REACTION_REMOVED, this.handleReaction)
}

This way we can retrieve the message on which the reaction has been added. Unfortunately, the Slack API only provides a light object as the message, without the attached list of reactions (how strange is this?), so we need to make another API call to retrieve this list.

handleReaction({ item }) {
  this.checkNeedToPostMessage(item).then(isValid => {
    if (isValid) {
      // Post the message on Twitter
    }
  })
}

checkNeedToPostMessage({ channel, ts }) {
  return this.api.reactions.get({
      channel,
      timestamp: ts,
      full: true
  }).then(({ message: { reactions } }) => {
    return this.vote(reactions) && this.checkAlreadyPosted(reactions);
  })
}

Now, we can send a list of reactions to the vote function and implement the rules described above. The use of lodash makes it simple to read and write the code.

vote(reactions) {   
  const plusReactions = _.find(reactions, { name: '+1' })   
  const minusReactions = _.find(reactions, { name: '-1' }) 
   
  if (!plusReactions || !minusReactions) {     
    return false   
  }    

  return plusReactions.count - minusReactions.count >= MIN_SCORE 
}

Now that we have a voting system, all we have to do next is to add 👍 and 👎 reactions to the new messages.

start() {
  super.start()

  this.rtm.on(RTM_EVENTS.MESSAGE, ({ subtype, thread_ts, channel, ts, text, message }) => {
    if (subtype || thread_ts) {
      return
    }

  this.api.reactions.add('+1', { channel, timestamp: ts })
      .then(() => this.api.reactions.add('-1', { channel, timestamp: ts }))
  })
  ...
})

Checking the subtype and the thread_ts variables allow us to differentiate messages in the original channel from edited messages or messages posted in a thread of the channel. We chained our promises to ensure that the reactions are always added in the same order.

Sending a tweet

Posting on Twitter is not really difficult once you installed the Twitter library:

const Twitter = require('twitter');

class TweetBot extends Bot {
  constructor(...args) {
    super(...args)

  this.twitter = new Twitter({
      consumer_key: process.env.TWITTER_CONSUMER_KEY,
      consumer_secret: process.env.TWITTER_CONSUMER_SECRET,
      access_token_key: process.env.TWITTER_ACCESS_TOKEN_KEY,
      access_token_secret: process.env.TWITTER_ACCESS_TOKEN_SECRET,
    });
  }
}

In the constructor of our bot, we initialize the Twitter library so that it can use the team’s account to post the messages. Then we implement the sendTweet method:

sendTweet({ text }) {
  const status = text.replace(/<([^>]*)>/g, '$1')
  return new Promise((resolve, reject) => {
    this.twitter.post('statuses/update', { status }, (error, tweets, response) => {
      if (error) {
        reject(error)
      } else {
        resolve(response)
      }
    })
  })
}

In this method several things are done. First, we edit the Slack message, to remove < and > that surround links. Then as the post method is only accepting callbacks, we wrap the call in a promise, allowing us to catch errors and response more easily.

Now that our post method is ready, we can add it to the handleReaction method:

handleReaction({ item }) {
  this.checkNeedToPostMessage(item).then(isValid => {
    if (isValid) {
      this.getMessage(item).then(message => {
        this.sendTweet(message)
      })
    }
  })
}

getMessage({ channel, ts }) {
  return this.api.channels.history(channel, {
    latest: ts,
    count: 1,
    inclusive: true
  }).then(({ messages }) => messages[0])
}

Here we need another method to get the message, as the Slack API doesn’t send the content of the message on the Reaction events. To retrieve a message, we need to call the history method that will send us back messages that correspond to criterias. To get a particular message, you need to pass the timestamp of the message as the latest timestamp, add the inclusive: true, and of course take the first element of the array.

One last thing to do before posting a message is checking that the message hasn’t already been posted. Let’s assume for now that the bot adds the :white_check_mark: or the :x: emoji when the message is posted. With this in mind, we can easily know if the message has been posted.

checkAlreadyPosted(reactions) {
  return _.some(reactions, ({ name, users }) => (name === 'white_check_mark' || name === 'x') && users.includes(this.rtm.activeUserId))
}

Here thanks to lodash, we check in the message reactions if the aforementioned emoji has been added by the bot.

Errors and message length

There are several errors to check and informations to display. We decided to managed only three cases: the success, the unknown error and the message length error. As we wrapped the post method in a promise, we can now manage success and errors in a simple fashion.

handleReaction({ item }) {
  ...
  this.sendTweet(message).then(() => this.addSuccessReaction(item), () => this.addErrorReaction(item))
  ...
}

addSuccessReaction({ channel, ts }) {
  return this.api.reactions.add('white_check_mark', { channel, timestamp: ts })
}

addErrorReaction({ channel, ts }) {
  return this.api.reactions.add('x', { channel, timestamp: ts })
}

This way, we add a check mark icon when the message is posted, or a red cross if a problem occurred while posting.

We don’t need to post the tweet to know the message is too long, so we created a method to check the message length and updated the method linked to the messages creation or update.

start() {
  super.start()

this.rtm.on(RTM_EVENTS.MESSAGE, ({ subtype, thread_ts, channel, ts, text, message }) => {
    if (subtype === 'message_changed') {
      if (this.sizeOf(message.text) > MAX_SIZE) {
        this.api.reactions.add('no_entry_sign', { channel, timestamp: message.ts })
      } else {
        this.api.reactions.remove('no_entry_sign', { channel, timestamp: message.ts })
      }
    }
    if (subtype || thread_ts) {
      return
    }

this.api.reactions.add('+1', { channel, timestamp: ts })
      .then(() => this.api.reactions.add('-1', { channel, timestamp: ts }))
      .then(() => {
        if (this.sizeOf(text) > MAX_SIZE) {
          this.api.reactions.add('no_entry_sign', { channel, timestamp: ts })
        }
      })
  })
  ...
})

sizeOf(message) {
  const urlRegex = /<https?:\/\/([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?>/g;
  return message.replace(urlRegex, ' '.repeat(23)).length
}

With this we can display an emoji showing that the text is too long. To understand the sizeOf method, you must know that Twitter automatically minifies the urls to a 23-character-long url.

Conclusion

Well, a picture is worth a thousand words:

During this hackathon, we managed to create a simple Slack bot that posts messages on Twitter. This first version is capable of tweeting text, can count votes and publish the message, and warns us if the message is too long or if there has been an error.

This bot is really simple and could be upgraded to send images, retweet or even post on other social medias. Theses features will likely be the subject of another hackathon, so stay tuned for more!

Hackathon V2 — Hello Twitter ! was originally published in theTribe on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mais vous êtes qui ?

Nous, nous sommes les sioux de theTribe, des développeurs, des aficionados du web et des choses bien faites. Nous sommes une grande famille qui s’est réunie autour de valeurs communes telles que le partage, l’entraide, l’excellence technique, mais bien sûr autour d’une passion commune pour le web. Nous développons principalement avec Symfony, React, Node.js, Angular, mais nous cherchons toujours de nouvelles technos à expérimenter.

Ce blog, y aura quoi dedans ?

Ce blog va nous permettre de nous exprimer sur plusieurs thèmes :

• Les sujets et problématiques techniques que nous avons pu rencontrer dans nos différents projets
• La vie de développeur chez theTribe, avec des présentations de technos, d’outils ou de méthodes que nous mettons en place
• Les chats
• Les hackathons que nous faisons de temps en temps
• Les revues de presse d’articles que nous avons trouvés intéressants ou instructifs
• Des retours de conférences/talks

Plutôt français ou anglais ?

Tout dépend de la technicité de l’article, de sa visée, de son auteur… En bref, pas de règle précise, il se peut que certains articles soient disponibles dans les deux langues (un peu comme celui-ci).

Bonne lecture !

Hello my English speaking friend, let’s talk about this blog shall we?

Who are you?

We are developers from theTribe, Internet and well-crafted-thing lovers. We are a big family gathered around common values such as sharing, helping each other, being technically excellent, and of course around our love for the web. We are mainly using Symfony, React, Node.js and Angular to develop, but we are always looking for new technologies to test.

What’s inside?

We will write about several topics:

• Technical Problems we came across and solutions we crafted on our projects
• Our life as developers at theTribe: technologies, tools or methods we are using
• Cats
• The hackathons we regularly do
• Press reviews of articles we thought of interest or instructive

English or French?

No precise rule here, it depends on the technical nature of the article, its aim, the author… Some articles might be available in both languages (like this one).

Good reading!

Hello world! was originally published in theTribe on Medium, where people are continuing the conversation by highlighting and responding to this story.

Who the hell will unlock the door ?

As we moved into our new office, we realized we didn’t have enough keys for everyone in the team, for the entrance of the building. When you don’t have the key, you have to call on the intercom to get the door open. Furthermore, our landlord isn’t a big fan of having 25 keys for a single office, so we gave the keys to the guys who begin early, and the rest of us just had to ring the bell. Easy, simple, no problem. Until the two guys with the keys are late or sick or someone gets mad because of the continuous intercom ringing between 9am and 10am. So we decided to take care of this by linking the intercom to our Slack team in order to be able to open the door from outside the office (or when we are too lazy to move 10 meters to open the door). Here was the subject for our first Hackathon session.

Software

The easiest and more secure way to handle the intercom via Internet for us was to connect a bot on the local network to Slack, and control this bot via Slack. Thus, the bot is isolated from the global network and cannot be hacked directly. This solution demands of course to trust Slack, and we made this choice willingly.

The first step was therefore to create a Slack bot user and to connect it to our team. Slack offers a relatively simple service for that (see documentation here); once the bot user created, it can be accessed directly from our code via Slack’s Real Time Messaging API (RTM API). Once connected, the code can intercept every message posted on the channel to trigger a callback.

The code

We decided to use NodeJS to program the bot, because it is rather simple to set up and the RTM API can be used quite simply with a single package.

The base code for connecting the bot to slack and listening to the events is the following:

var RtmClient = require('@slack/client').RtmClient; 
var RTM_EVENTS = require('@slack/client').RTM_EVENTS;  

rtm.start();  

rtm.on(RTM_EVENTS.MESSAGE, function(message) {   
  // Callback triggered every time a message is sent to a channel    where   
  // the bot is present or directly to the bot via private message 
});

The second problem was to connect the bot to the Raspberry Pi’s pins, in order to send electrical signals to the relay and then open the door (see Hardware).

Fortunately, a library has been developed just to control the pins! It also works with events, and it’s rather simple to use too:

var gpio = require('rpi-gpio');  

// Set up a channel for read or write 
gpio.setup(channel [, direction, edge], callback);  

// Write the value of a channel 
gpio.write(channel, value, callback);

With these elementary bricks, it was then easy to write the code to open the door, and with a bit of debug, to make it work.

require('dotenv').load();  

var _ = require('lodash'); 
var gpio = require('rpi-gpio'); 
var RtmClient = require('@slack/client').RtmClient; 
var RTM_EVENTS = require('@slack/client').RTM_EVENTS;
  
var rtm = new RtmClient(process.env.SLACK_API_TOKEN, { logLevel: 'warning' }); 
 
var PIN_BUTTON = 6; // Arbitrary pin connected to the opening button var PUSH_BUTTON_DELAY = 3000; // Delay during which the opening signal is sent  

rtm.start(); 
 
var lock = false;  

function openTheDoor(cb) {
  if (lock) return;
  lock = true;
  gpio.setup(PIN_BUTTON, gpio.DIR_OUT, function() {
    gpio.write(PIN_BUTTON, false, function(err) {
      if (err) throw err;
      setTimeout(function() {
        gpio.write(PIN_BUTTON, true, function(error) {
          if (error) throw error;
          lock = false;
          if (cb) cb();
        });
      }, PUSH_BUTTON_DELAY);
    });
  });
}

// Chat bot
rtm.on(RTM_EVENTS.MESSAGE, function(message) {
  function contains(needles) {
    return message.text && _.every(needles, function(needle) {
      return message.text.toLowerCase().indexOf(needle.toLowerCase()) !== -1;
    });
  }

if (contains(['<@' + rtm.activeUserId + '>', 'open'])) {
    rtm.sendMessage('I will now open the door!', message.channel);
    openTheDoor(function() {
      rtm.sendMessage('The door is opened', message.channel);
    });
  }
});

Service

The last step was to encapsulate the bot in a service to run as a background process and, ideally, boot on startup in case of power cut.

Since our Raspbian (a Debian-based OS optimized for Raspberry Pi) uses Systemd to manage the services, we configured a new service named thedoor as follows:

[Unit] 
Description=theDoor 
After=network.target  

[Service] 
Type=simple 
ExecStart=/usr/bin/nodejs /home/pi/thedoor/index.js 
Restart=always  

[Install] 
WantedBy=default.target

Finally, we configured it as a service, which needs to be activated with systemctl enable thedoor.

Hardware

First, we had to check how our intercom is working in order to know what we can do with it. We looked up for electrical plans on the Internet and found this wiring diagram:

Thanks to that, we know that when we are pressing the opening button, it creates a contact allowing the current to pass through the door-opening system. All we have to do is connect the two parts linked to the button to open the door whenever we want.

To do so, we need to isolate the control system (the Raspberry) from the active system (the intercom) because they do not work under the same voltage and amperage. We selected the following relay to do the job:

The commutation voltage is around 3V and can handle a lot more than the 15V we have in the door-opening circuit. This relay allows us to close the door-opening circuit when we have 5V on an out pin of the Raspberry. Moreover, having a spare relay on the component allows us to add other features to the system if need be.

With everything in mind, we came up with this simple wiring diagram for our project:

The button and the relay are wired in parallel, allowing us to use both our Raspberry and the intercom button to close the circuit and open the door.

After some welding, we connected our system to the intercom:

The screws used to connect the button to the door-opening circuit make it easy for us to add our system without damaging the intercom (We don’t want to upset our landlord, do we?).

Conclusion

It took us 4 hours for an approximate cost of 60€, but the result is here, we can now open the door thanks to our smartphones with a simple message on Slack! No more ringing bell in the morning, welcome Slack notifications!

Our first Hackathon was originally published in theTribe on Medium, where people are continuing the conversation by highlighting and responding to this story.