# Ajouter une logique côté serveur

Validez et traitez les données et les actions de l'utilisateur dans votre application à l'aide de code back-end.

> #### Utiliser l’API Accounts v2 pour représenter les clients
> 
> L’API Accounts&nbsp;v2 est généralement disponible pour les utilisateurs de Connect et en aperçu public pour les autres utilisateurs de Stripe. Si vous avez accès à l’aperçu Accounts&nbsp;v2, vous devez spécifier une [version d’aperçu](https://docs.stripe.com/api-v2-overview.md#sdk-and-api-versioning) dans votre code.
> 
> Pour accéder à l’aperçu Accounts&nbsp;v2, rendez-vous sur [aperçus et fonctionnalités de Account](https://dashboard.stripe.com/settings/previews) dans votre Dashboard et activez **Moyens de paiement réutilisables pour les virements internationaux**.
> 
> Dans la plupart des cas d’usage, nous vous recommandons de [modéliser vos clients en tant qu’objets Account configurés par le client](https://docs.stripe.com/accounts-v2/use-accounts-as-customers.md), plutôt que d’utiliser des objets [Customer](https://docs.stripe.com/api/customers.md).

Avec les applications Stripe, vous pouvez ajouter une logique côté serveur avec un back-end auto-hébergé. Avec un service back-end auto-hébergé, vous pouvez&nbsp;:

- Intégrez en toute sécurité les systèmes tiers qui nécessitent une intégration côté serveur.
- Inscrivez-vous aux événements de *webhook* (A webhook is a real-time push notification sent to your application as a JSON payload through HTTPS requests) de Stripe et synchronisez Stripe avec d’autres systèmes.
- Utilisez une logique d’application à long terme qui s’exécute lorsque l’utilisateur ferme le navigateur.
- Développez des applications qui offrent des fonctionnalités semblables à des tâches cron pour planifier des actions spécifiques.
![Organigramme du back-end de l'application](https://b.stripecdn.com/docs-statics-srv/assets/app-backend.46a6d040d44872962a59728aaa65ee06.png)

Comment le back-end auto-hébergé est-il lié à l’application&nbsp;?

## Authentifier les utilisateurs entre votre interface utilisateur et le back-end de votre application

Pour authentifier un utilisateur à partir du Dashboard, le back-end a besoin d’une signature contenant la clé secrète partagée ainsi que le compte et l’ID de l’utilisateur actuellement connecté au Dashboard. Si votre utilisateur n’est pas autorisé à appeler l’API, Stripe renvoie une [erreur d’autorisation](https://docs.stripe.com/error-handling.md?lang=node#permission-errors).

## Before you begin

1. Assurez-vous que votre service back-end peut envoyer et recevoir des requêtes HTTP. Si vous n’avez jamais créé de serveur API, essayez notre [outil interactif pour la création d’endpoints de webhook](https://docs.stripe.com/webhooks/quickstart.md).

2. Créez votre clé secrète partagée en [chargeant votre application](https://docs.stripe.com/stripe-apps/upload-install-app.md)&nbsp;:

   ```bash
   stripe apps upload
   ```

   Ne vous inquiétez pas si vous n’avez pas terminé le développement de la version actuelle de votre application, le chargement ne mettra pas à jour votre application en mode production.

3. Obtenez la clé secrète de votre application pour vérifier la signature dans votre back-end&nbsp;:

   a. Accédez aux informations de votre *application Stripe* (An app that you can build on top of Stripe to customize the functionality of the Stripe Dashboard UI, leverage Stripe user data, store data on Stripe, and more) en sélectionnant votre application à partir de la section [Apps](https://dashboard.stripe.com/apps).

   b. Sous l’ID de l’application, cliquez sur le menu de débordement (⋯), puis sur **Clé secrète de signature** pour ouvrir la boîte de dialogue correspondante.

   c. Cliquez sur le Presse-papiers :clipboard: pour copier la clé secrète de votre application à partir de la boîte de dialogue Clé secrète de signature.

> Exécutez `stripe apps upload` au moins une fois avant d’utiliser `fetchStripeSignature` lors du développement local. Cela génère la clé secrète de signature dont la fonction a besoin pour fonctionner en mode aperçu.

### Envoyer une requête signée
![Envoyer une requête signée](https://b.stripecdn.com/docs-statics-srv/assets/authenticate-ui-extension.9e45231756741ade2e1a73f56585864c.png)

Pour envoyer une requête signée au back-end de l’application&nbsp;:

1. Obtenez la signature actuelle à l’aide de la fonction asynchrone [fetchStripeSignature](https://docs.stripe.com/stripe-apps/reference/extensions-sdk-api.md#fetchStripeSignature).
2. Ajoutez la signature à l’en-tête `Stripe-Signature`.
3. Incluez les objets `user_id` et `account_id` dans la requête.
4. Sur le back-end de l’application, vérifiez que la requête comprenne la signature, la clé secrète de l’application, `user_id` et `account_id`.

Consultez un [exemple d’envoi d’une requête signée avec des données supplémentaires](https://docs.stripe.com/stripe-apps/build-backend.md#send-a-signed-request-with-additional-data).

Voici un exemple de requête d’une application Stripe avec l’en-tête `Stripe-Signature`&nbsp;:

```ts
import {fetchStripeSignature} from '@stripe/ui-extension-sdk/utils';

const App = ({ userContext, environment }: ExtensionContextValue) => {
  const makeRequestToMyBackend = async (endpoint, requestData) => {
    // By default the signature is signed with user id and account id.
    const signaturePayload = {
      user_id: userContext?.id,
      account_id: userContext?.account.id,
    };
    return fetch(`https://example.com/${endpoint}/`, {
      method: 'POST',
      headers: {
        'Stripe-Signature': await fetchStripeSignature(),
        'Content-Type': 'application/json',
      },
      // Include the account ID and user ID in the body to verify on backend.
      body: JSON.stringify({
        ...requestData,
        ...signaturePayload,
      }),
    });
  };
  ...
}
```

Exemple de back-end vérifiant la requête&nbsp;:

Veuillez noter que l’ordre et le nom des champs de la charge utile ont une incidence sur la vérification de la signature. `user_id` précède `account_id`, et l’objet résultant est le suivant&nbsp;: `{ user_id, account_id }`account

```js
// Set your secret key. Remember to switch to your live secret key in production.
// See your keys here: https://dashboard.stripe.com/apikeys
const stripe = require('stripe')(process.env.STRIPE_API_KEY);
const express = require('express');

// Find your app's secret in your app settings page in the Developers Dashboard.
const appSecret = 'absec_...';

// This example uses Express.
const app = require('express')();
app.use(express.json());

// Match the raw body to content type application/json.
app.post('/do_secret_stuff', (request, response) => {
  const sig = request.headers['stripe-signature'];
  // Retrieve user id and account id from the request body
  const payload = JSON.stringify({
    user_id: request.body['user_id'],
    account_id: request.body['account_id']
  });
  try {
    // Verify the payload and signature from the request with the app secret.
    stripe.webhooks.signature.verifyHeader(payload, sig, appSecret);
  } catch (error) {
    response.status(400).send(error.message);
  }
  // Handle the request by returning a response
  // to acknowledge receipt of the event.
  response.json({ success: true });
});

app.listen(3000, () => console.log('Running on port 3000'));
```

### Envoyer une requête signée avec des données supplémentaires

Vous pouvez authentifier un utilisateur en envoyant une requête signée avec une charge utile (données supplémentaires). Lorsque vous appelez la fonction `fetchStripeSignature` avec une requête de données supplémentaires, vous créez une signature avec `user_id`, `account_id` et la charge utile supplémentaire que vous avez transmise à la fonction. Par défaut, Stripe Apps utilise `user_id` et `account_id` pour générer la chaîne de signature.

Exemple de génération d’une clé secrète avec une charge utile supplémentaire&nbsp;:

```js
// A valid payload object has keys of type string
// and values of type string, number, or boolean.
const payload = {
  "transaction_id": 'ipi_1KRmFUFRwUQjTSJEjRnCCPyV',
  "amount": 100,
  "livemode": false,
};

(async () => {
  fetch(`https://example.com/do_more_secret_stuff/`, {
    method: 'POST',
    headers: {
      'Stripe-Signature': await fetchStripeSignature(payload),
      'Content-Type': 'application/json',
    },
    // Append the account ID and user ID in the body to verify on backend.
    body: JSON.stringify({
      ...payload,
      user_id: 'usr_K6yd2CbXLO9A5G',
      account_id: 'acct_1JSkf6FRwUQjTSJE',
    }),
  });
})();
```

Exemple de back-end vérifiant la signature générée avec une charge utile supplémentaire&nbsp;:

```js
// Match the raw body to content type application/json.
app.post('/do_more_secret_stuff', (request, response) => {
  try {
    // Verify the signature from the header and the request body that
    // contains the additional data, user ID, and account ID with the app secret.
    stripe.webhooks.signature.verifyHeader(request.body, sig, appSecret);
  } catch (error) {
    response.status(400).send(error.message);
  }
  // Handle the request by returning a response
  // to acknowledge receipt of the event.
  response.json({ success: true });
});
```

### Vérifier les rôles d’utilisateur (facultatif)

Vous pouvez vérifier les rôles d’utilisateur affectés à un `user_id` donné en incluant la clé `stripe_roles` dans la charge utile. Fournissez-la avec `userContext?.roles`, qui renvoie une liste de [RoleDefinitions](https://docs.stripe.com/stripe-apps/reference/extensions-sdk-api.md#roledefinition). Si aucun rôle de la charge utile n’est affecté au paramètre `user_id` fourni, `fetchStripeSignature` renvoie une erreur de requête non valide (400).

```js
// Provide this special key in the same way you'd
// provide any other key to the additional payload.
const payload = {
  "stripe_roles": userContext?.roles,
};

fetch(`https://example.com/do_more_secret_stuff/`, {
  method: 'POST',
  headers: {
    'Stripe-Signature': await fetchStripeSignature(payload),
    'Content-Type': 'application/json',
  },
  // Append the account ID and user ID in the body to verify on backend.
  body: JSON.stringify({
    ...payload,
    user_id: 'usr_K6yd2CbXLO9A5G',
    account_id: 'acct_1JSkf6FRwUQjTSJE',
  }),
});
```

### Créer et faire expirer des clés secrètes

En cas de compromission de votre clé secrète, vous pouvez faire expirer la clé secrète actuelle de votre application immédiatement ou dans un délai de 24&nbsp;heures pour mettre à jour la clé secrète de l’application dans votre back-end. Pendant cette période, deux&nbsp;clés secrètes sont actives pour l’endpoint, la clé compromise et la nouvelle clé générée. Stripe génère une signature par clé secrète jusqu’à l’expiration.

Pour créer et faire expirer une clé secrète d’application&nbsp;:

1. Accédez aux informations de votre *application Stripe* (An app that you can build on top of Stripe to customize the functionality of the Stripe Dashboard UI, leverage Stripe user data, store data on Stripe, and more) en sélectionnant cette dernière à partir de la section [Applications](https://dashboard.stripe.com/apps).
2. Dans l’en-tête de la page, cliquez sur le menu de débordement (⋯), puis sur **Clé secrète de signature** pour ouvrir la boîte de dialogue correspondante.
3. Cliquez sur **Faire expirer la clé secrète** dans la boîte de dialogue Clé secrète de signature pour ouvrir la boîte de dialogue Faire expirer la clé secrète.
4. Sélectionnez une durée d’expiration pour la clé secrète actuelle de votre application.
5. Cliquez sur **Faire expirer la clé secrète**.

### Gérer le partage de ressources entre origines multiples (CORS)

Le [CORS (partage de ressources entre origines multiples)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) est d’une aide importante pour sécuriser les applications face aux [attaques «&nbsp;cross-site scripting&nbsp;» (XSS)](https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scripting). Vous devez mettre en œuvre une approche spécifique pour gérer les en-têtes de requêtes d’origines multiples, car les extensions d’interface utilisateur d’une application Stripe sont nécessairement d’origines multiples et s’exécutent dans un [iframe d’environnement de test](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#sandbox).

Pour que votre extension d’interface utilisateur puisse récupérer les données de votre service back-end, vous devez configurer ce dernier pour qu’il effectue les actions suivantes&nbsp;:

- Autoriser les requêtes via la [méthode Options](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS).
- Pour autoriser les requêtes provenant d’origines `null`, définissez `Access-Control-Allow-Origin` sur `*`.

> Les extensions d’interface utilisateur ont une origine nulle, car elles s’exécutent dans un [iframe sécurisé d’environnement de test](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#sandbox) pour des raisons de sécurité.

De nombreux frameworks back-end disposent de bibliothèques et proposent des conseils pour vous aider à gérer le CORS. Référez-vous à la documentation de votre framework pour des conseils plus précis.

Pour authentifier le fait qu’une requête provient de Stripe pour le compte d’un utilisateur ou d’un compte particulier, consultez la section [Authentifier les utilisateurs entre votre interface utilisateur et votre back-end](https://docs.stripe.com/stripe-apps/build-backend.md#authenticate-ui-to-backend).

> Configurez uniquement les endpoints authentifiés et ceux avec lesquels l’extension d’interface utilisateur communique pour utiliser `Access-Control-Allow-Origin: *`. Les endpoints non authentifiés sont vulnérables aux attaques [CSRF](https://developer.mozilla.org/en-US/docs/Glossary/CSRF) si aucune autre mesure n’est en place.

## Utiliser les API de Stripe

Pour interagir avec Stripe, vous pouvez lancer et authentifier vos requêtes sur l’API Stripe.

### Authentification des requêtes

Pour authentifier vos requêtes, utilisez la clé API de votre compte marchand existant pour interagir avec Stripe et spécifiez le `stripeAccountId` de l’utilisateur.

Pour les appels à l’API côté serveur, vous pouvez effectuer des requêtes en tant que comptes connectés à l’aide de l’en-tête spécial `Stripe-Account` et de l’identifiant de compte Stripe (qui commence par le préfixe `acct_`) de l’utilisateur de votre plateforme. Voici un exemple qui montre comment [créer un PaymentIntent](https://docs.stripe.com/api/payment_intents/create.md) avec la [clé API secrète](https://docs.stripe.com/keys.md) de votre plateforme et l’identifiant du [compte](https://docs.stripe.com/api/accounts.md) de votre utilisateur.

```curl
curl https://api.stripe.com/v1/payment_intents \
  -u "<<YOUR_SECRET_KEY>>:" \
  -H "Stripe-Account: {{CONNECTEDACCOUNT_ID}}" \
  -d amount=1000 \
  -d currency=usd \
  -d "automatic_payment_methods[enabled]=true"
```

L’approche d’en-tête `Stripe-Account` est implicite dans toute requête API qui inclut l’ID du compte Stripe dans l’URL. Voici un exemple qui montre comment [récupérer un compte](https://docs.stripe.com/api/accounts/retrieve.md) avec l’identifiant du [compte](https://docs.stripe.com/api/accounts.md) de votre utilisateur dans l’URL.

```curl
curl https://api.stripe.com/v1/accounts/{{CONNECTEDACCOUNT_ID}} \
  -u "<<YOUR_SECRET_KEY>>:"
```

En outre, toutes les bibliothèques côté serveur de Stripe prennent en charge cette approche par requête, comme illustré dans l’exemple suivant&nbsp;:

#### Ruby

```ruby
client = Stripe::StripeClient.new("{{PLATFORM_SECRET_KEY}}")
client.v1.customers.create(
  {email: 'person@example.com'},
  {stripe_account: '{{CONNECTED_STRIPE_ACCOUNT_ID}}'}
)

# Fetching an account just needs the ID as a parameter
client.v1.accounts.retrieve('{{CONNECTED_STRIPE_ACCOUNT_ID}}')
```

### Appeler votre back-end auto-hébergé depuis l’extension d’interface utilisateur

Lorsque vous effectuez des requêtes depuis l’extension d’interface utilisateur vers le back-end, [envoyez une signature avec votre requête](https://docs.stripe.com/stripe-apps/build-backend.md#authenticate-ui-to-backend) pour valider la légitimité de vos requêtes. Depuis l’extension d’interface utilisateur, transmettez le `stripeAccountId` de l’utilisateur actif pour pouvoir effectuer des requêtes de back-end au nom de cet utilisateur.

```javascript

// Don't put any keys in code. See https://docs.stripe.com/keys-best-practices.
// Find your keys at https://dashboard.stripe.com/apikeys.
const stripe = require('stripe')('<<YOUR_SECRET_KEY>>');
const express = require("express");
const app = express();

app.use(express.static("public"));
app.use(express.json());

app.post("/api/data", async (req, res) => {
  const { stripeAccountId } = req.body;

  const customer = await stripe.customers.create({
    description: 'My First Test Customer (created for API docs)',
  }, {
    stripeAccount: stripeAccountId,
  });

  res.send({
    data: []
  });
});

app.listen(3000, () => console.log("Node server listening on port 3000!"));
```

## Appeler d’autres API

Depuis votre back-end auto-hébergé, vous pouvez appeler n’importe quelle API, qu’il s’agisse de la vôtre ou de celle d’un autre développeur ou d’une autre entreprise.

Pour en savoir plus sur le stockage des identifiants et des tokens dans votre application, consultez la [page consacrée à ce sujet](https://docs.stripe.com/stripe-apps/store-secrets.md).

Si vous avez besoin de transmettre des informations utilisateur de Stripe vers un autre service, utilisez le `stripeAccountId` transmis depuis l’extension d’interface utilisateur.

```javascript
const express = require('express');
const fetch = require('isomorphic-fetch');
const app = express();

app.use(express.static('public'));
app.use(express.json());

app.get('/api/time', async (req, res) => {
  fetch('http://worldclockapi.com/api/json/est/now')
    .then((response) => response.json())
    .then((data) => {
      res.send({
        data: data,
      });
    });
});

app.listen(3000, () => console.log('Node server listening on port 3000!'));
```

Vous pouvez également [appeler une API tierce depuis l’extension d’interface utilisateur](https://docs.stripe.com/stripe-apps/build-ui.md#use-third-party-apis).

## Recevoir des notifications d’événement concernant votre application

Écoutez les événements (comme les installations et désinstallations des utilisateurs) sur votre application Stripe en utilisant des *webhooks* (A webhook is a real-time push notification sent to your application as a JSON payload through HTTPS requests) entrants pour permettre à votre intégration de déclencher automatiquement des réactions sur votre back-end, telles que&nbsp;:

- La création de comptes utilisateur
- La mise à jour d’autorisations
- La désactivation d’un compte utilisateur et la suppression des données

### Recevoir des événements

Vous pouvez recevoir des événements de la part de Stripe pour une application qui n’est accessible qu’à votre compte ou publiée sur l’*App Marketplace* (A marketplace to browse, search, and install Stripe apps)&nbsp;:

#### Publication sur l'App Marketplace

Pour recevoir les événements d’une application publiée sur l’*App Marketplace* (A marketplace to browse, search, and install Stripe apps)&nbsp;:

1. [Gérez les événements webhook dans le back-end de votre application](https://docs.stripe.com/webhooks.md#webhook-endpoint-def).
2. [Enregistrer un endpoint de webhook](https://docs.stripe.com/webhooks.md) dans le Dashboard Stripe et sélectionnez **Écouter les événements sur les comptes connectés** lors de l’enregistrement de votre endpoint de webhook.
3. Ajoutez l’autorisation `event_read` à votre application&nbsp;:
   ```bash
   stripe apps grant permission "event_read" "Allows reading event data from users who have installed the app"
   ```
4. Pour chaque événement que vous écoutez à l’aide de votre endpoint de webhook, ajoutez l’autorisation correspondante&nbsp;:
   ```bash
   stripe apps grant permission "PERMISSION_NAME" "EXPLANATION"
   ```
Remplacez&nbsp;:
   - `PERMISSION_NAME` avec le [nom de l’autorisation pour un événement](https://docs.stripe.com/stripe-apps/reference/permissions.md).
   - `EXPLANATION` avec une explication relative à l’autorisation d’accès. Les utilisateurs voient cette explication lorsqu’ils installent votre application. Par exemple&nbsp;: «&nbsp;Autorise la lecture des données d’événements des utilisateurs ayant installé l’application.&nbsp;»

#### Privé pour votre compte

Pour recevoir les événements d’une application qui n’est accessible qu’aux utilisateurs de votre compte&nbsp;:

1. Gérez les [événements webhook](https://docs.stripe.com/webhooks.md#webhook-endpoint-def) dans le back-end de votre application.
2. [Enregistrer un endpoint de webhook](https://docs.stripe.com/webhooks.md) dans le Dashboard Stripe.

Lorsqu’une entreprise déclenche un événement, Stripe fournit l’objet [Event](https://docs.stripe.com/api/events/object.md) suivant. Cet événement inclut la propriété `account` qui précise l’ID du compte de l’entreprise à l’origine de l’événement&nbsp;:

```json
{
  "id": "evt_orWziM4j7CiRL8",
  "livemode": true,
  "object": "event",
  "type": "apps.install.created",
  "account": "acct_orWziM4j7CiRL8",
  "pending_webhooks": 2,
  "created": 1349654313,
  "data": {...}
}
```

En utilisant l’attribut `account`, vous pouvez&nbsp;:

- Garder un œil sur le nombre d’entreprises qui installent et désinstallent votre application.
- [Effectuer des appels à l’API au nom de vos utilisateurs à l’aide de Stripe Connect](https://docs.stripe.com/connect/authentication.md).

### Événements pour Stripe Apps

Outre les [types d’événements pris en charge par Stripe](https://docs.stripe.com/api/events/types.md), les applications Stripe prennent en charge les événements suivants&nbsp;:

| Action du marchand | Événement webhook obtenu envoyé au back-end de l’application |
| --- | --- |
| Installez votre application | [apps.install.created](https://docs.stripe.com/api/events/types.md#event_types-apps.install.created) |
| Mettez à jour ou ré-autorisez votre application | [apps.install.updated](https://docs.stripe.com/api/events/types.md#event_types-apps.install.updated) |
| Désinstallez votre application | [apps.install.deleted](https://docs.stripe.com/api/events/types.md#event_types-apps.install.deleted) |

Dans les versions de l’API antérieures au 30&nbsp;septembre&nbsp;2026, ces événements sont nommés `app.install.created`, `app.install.updated` et `app.install.deleted`. Stripe envoie également [account.application.authorized](https://docs.stripe.com/api/events/types.md#event_types-account.application.authorized) lorsqu’un compte se connecte à votre application ou l’installe, et [account.application.deauthorized](https://docs.stripe.com/api/events/types.md#event_types-account.application.deauthorized) lorsqu’un compte s’en déconnecte ou la désinstalle.

Pour en savoir plus sur l’écoute des événements d’installation pour votre application et sur les données retournées, consultez [Écouter les événements](https://docs.stripe.com/stripe-apps/events.md).

## Le comportement de l’événement dépend du mode d’installation

Vos utilisateurs peuvent installer des applications en mode production, dans l’environnement de test en mode test ou dans un environnement de test général. Définissez les webhooks conformément aux directives suivantes&nbsp;:

- Si une application privée est installée dans un environnement de test général, cette instance d’application envoie uniquement des événements aux endpoints de webhook de ce même environnement de test.
- Si une application publique est installée dans un environnement de test général, cette instance d’application envoie des événements aux endpoints de webhook de l’environnement de test géré par le développeur de l’application.
- Si l’application est installée en mode réel, cette instance d’application envoie uniquement des événements aux endpoints de webhook du mode production.
- Si l’application est installée dans l’environnement de test en mode test mais pas en mode production, cette instance d’application envoie uniquement des événements aux endpoints de webhook de cet environnement de test en mode test.
- Si une application publique est installée à la fois en mode production et dans l’environnement de test en mode test, l’instance installée dans l’environnement de test en mode test envoie des événements aux endpoints de webhook de l’environnement de test en mode test ET du mode production. En revanche, l’instance installée en mode production envoie des événements uniquement aux endpoints de webhook du mode production. Pour une application privée, les événements sont envoyés uniquement aux endpoints de webhook du même environnement.

`livemode=false` identifie un événement hors production. Cela ne permet pas de distinguer un environnement de test général d’un environnement de test en mode test.

Configurez le `/webhook` Connect pour le mode production et l’environnement de test du mode test, puis utilisez le extrait de code suivant pour les deux environnements. Consultez la [documentation sur les webhooks](https://docs.stripe.com/webhooks.md#example-endpoint) pour obtenir un exemple complet de l’endpoint.

#### Ruby

```ruby
require 'sinatra'
require 'json'

post '/webhook' do
  event = JSON.parse(request.body.read)

  if event['livemode']
    puts "Handling live event: #{event}"
    # Handle live events
    handle_live_event(event)
  else
    puts "Handling test event: #{event}"
    # Handle test events
    handle_test_event(event)
  end

  status 200
  body 'Event received'
end
```

### Résolution des problèmes

Si vous ne recevez pas les événements attendus, vérifiez votre configuration au cas où vous auriez omis l’un des éléments suivants&nbsp;:

- Assurez-vous que les webhooks en mode production utilisent des clés du mode production et que les webhooks de l’environnement de test en mode test utilisent des clés du mode test.
- Pour les événements en mode production, assurez-vous que le compte d’installation est activé.
- Assurez-vous que votre application peut gérer aussi bien les événements du mode production que ceux de l’environnement de test en mode test.
- Le déclenchement d’événements de test ne reproduit pas le comportement des événements en mode production, sauf s’il est explicitement configuré dans la configuration de l’application.

### Tester des webhooks en local

Vous pouvez tester les webhooks en local pour&nbsp;:

- Une application qui n’est disponible que pour les utilisateurs de votre compte et qui écoute les événements sur votre propre compte
- Une application disponible sur le Stripe App Marketplace et qui écoute les événements sur les comptes qui ont installé votre application

Pour tester des webhooks en local&nbsp;:

1. [Installer l’interface de ligne de commande Stripe](https://docs.stripe.com/cli.md).

2. Authentifiez votre compte&nbsp;:

   ```bash
   stripe login
   ```

3. Ouvrez deux fenêtres de terminal&nbsp;:

   - Dans une fenêtre de terminal, [configurez le transfert d’événements](https://docs.stripe.com/webhooks.md#local-listener)&nbsp;:

     #### Privée pour votre compte uniquement

     ```bash
       stripe listen --forward-to localhost:{{PORT}}/webhook
     ```

     #### Publication sur l'App Marketplace

     ```bash
     stripe listen --forward-connect-to localhost:{{PORT}}/webhook
     ```

   - Dans l’autre fenêtre de terminal, [déclenchez des événements pour tester votre intégration des webhooks](https://docs.stripe.com/webhooks.md#trigger-test-events)&nbsp;:

     #### Privée pour votre compte uniquement

     ```bash
       stripe trigger {{EVENT_NAME}}
     ```

     #### Publication sur l'App Marketplace

     ```bash
     stripe trigger --stripe-account {{EVENT_NAME}}
     ```

Pour plus d’informations, consultez notre documentation relative au [test d’un point de terminaison de webhook](https://docs.stripe.com/webhooks.md#local-listener).

## See also

- [Créer une interface utilisateur](https://docs.stripe.com/stripe-apps/build-ui.md)
- [Charger et installer votre application](https://docs.stripe.com/stripe-apps/upload-install-app.md)
- [Publier votre application](https://docs.stripe.com/stripe-apps/publish-app.md)
