# Ricevi gli eventi Stripe nell'endpoint del tuo webhook

Ascolta gli eventi di Stripe sul tuo endpoint webhook così la tua integrazione può attivare automaticamente le reazioni.

## Start here: Install agent skills

Stripe recommends using official skills to integrate with the API using best practices. Follow the instructions below to learn how.

**Tip: Use curl instead of Fetch tools.** Skills are detailed 10–20 KB markdown files. Fetch tools summarize them. `curl -sL` guarantees the full content.

**Using `npx skills`**: Check if `npx` is installed on the system. If `npx` is available, run `npx skills add https://docs.stripe.com --list` to list available skills, then run `npx skills add https://docs.stripe.com --yes --skill <skill-name> <--skill other-skills>` to install individual skills.

**If `npx skills` isn’t available**: You can use curl to fetch the index of available skills, what they do, and their files from `https://docs.stripe.com/.well-known/skills/index.json`. To download a skill and its related files, use curl to download them from `https://docs.stripe.com/.well-known/skills/<filepath>`.

For this article, we recommend using these skills: `stripe-best-practices`

> #### Invia eventi all'account AWS o all'abbonamento Azure
> 
> Puoi inviare eventi direttamente ad [Amazon EventBridge](https://docs.stripe.com/event-destinations/eventbridge.md) o alla [Griglia di eventi di Azure](https://docs.stripe.com/event-destinations/eventgrid.md) come destinazioni degli eventi.

Crea una destinazione dell’evento per ricevere eventi in un endpoint del webhook HTTPS. Dopo aver registrato un endpoint del webhook, Stripe può inviare i dati degli eventi in tempo reale all’endpoint del webhook della tua applicazione quando si verificano [eventi](https://docs.stripe.com/event-destinations.md#events-overview) nel tuo account Stripe. Stripe utilizza HTTPS per inviare eventi del webhook alla tua app come payload JSON che include un [oggetto Event](https://docs.stripe.com/api/events.md).

La ricezione degli eventi webhook ti aiuta a rispondere a eventi asincroni, come quando la banca di un cliente conferma un pagamento, un cliente contesta un addebito o un pagamento ricorrente va a buon fine.

## Inizia

Iniziare a ricevere eventi webhook nella tua app:

1. Crea un gestore dell’endpoint del webhook per ricevere le richieste POST dei dati degli eventi.
1. Testa localmente il gestore dell’endpoint del webhook utilizzando la CLI di Stripe.
1. Crea una nuova [destinazione evento](https://docs.stripe.com/event-destinations.md) per il tuo endpoint del webhook.
1. Proteggi l’endpoint del webhook.

Puoi registrare e creare un endpoint per gestire diversi tipi di eventi contemporaneamente o impostare singoli endpoint per eventi specifici.

## Comportamenti del tipo di evento non supportati per le destinazioni degli eventi dell’organizzazione

Stripe invia la maggior parte dei tipi di evento in modo asincrono, ma attende una risposta per alcuni tipi di evento. In questi casi, Stripe si comporta in modo diverso a seconda che la destinazione dell’evento risponda o meno.

Se la destinazione dell’evento riceve eventi dell’[Organizzazione](https://docs.stripe.com/get-started/account/orgs.md), quelli che richiedono una risposta hanno le seguenti limitazioni:

- Non puoi abbonarti a `issuing_authorization.request` per le destinazioni dell’organizzazione. Per iscriverti a questo tipo di evento, configura invece un [endpoint del webhook](https://docs.stripe.com/webhooks.md#example-endpoint) in un account Stripe all’interno dell’organizzazione. Usa `issuing_authorization.request` per autorizzare le richieste di acquisto in tempo reale.
- Le organizzazioni che ricevono `checkout_sessions.completed` non sono in grado di [gestire il comportamento di reindirizzamento](https://docs.stripe.com/checkout/fulfillment.md#redirect-hosted-checkout) quando si incorpora [Checkout](https://docs.stripe.com/payments/checkout.md) direttamente nel proprio sito web o si reindirizzano i clienti a una pagina di pagamento in hosting su Stripe. Per influenzare il comportamento di reindirizzamento di Checkout, elaborare questo tipo di evento con un [endpoint webhook](https://docs.stripe.com/webhooks.md#example-endpoint) configurato in un account Stripe all’interno dell’organizzazione.
- Le organizzazioni di destinazione che rispondono senza successo a un evento `invoice.created` non possono influire sulla [finalizzazione automatica delle fatture quando si utilizza la riscossione automatica](https://docs.stripe.com/billing/subscriptions/webhooks.md#understand). È necessario elaborare questo tipo di evento con un [endpoint webhook](https://docs.stripe.com/webhooks.md#example-endpoint) configurato in un account Stripe all’interno dell’organizzazione per attivare la finalizzazione automatica delle fatture.

## Crea un gestore

Configura una funzione endpoint HTTP o HTTPS in grado di accettare richieste webhook con un metodo POST. Se stai ancora sviluppando la tua funzione endpoint su dispositivi locali, questa può utilizzare il protocollo HTTP. Quando sarà accessibile pubblicamente, la funzione endpoint del webhook deve utilizzare il protocollo HTTPS.

Configura la funzione dell’endpoint in modo che:

- gestisca le richieste POST con un payload JSON costituito da un [oggetto Event](https://docs.stripe.com/api/events/object.md);
- Per i gestori di eventi dell’[organizzazione](https://docs.stripe.com/get-started/account/orgs.md), controlla il valore `context` per determinare quale account dell’organizzazione ha generato l’evento, quindi imposta l’intestazione `Stripe-Context` corrispondente al valore di `context`.
- Restituisce rapidamente un codice di stato OK (`2xx`) prima di qualsiasi logica complessa che potrebbe causare un timeout. Ad esempio, devi restituire una risposta `200` prima che la fattura di un cliente venga aggiornata come pagata nel sistema contabile.

> - Utilizza il nostro [generatore interattivo di endpoint webhook](https://docs.stripe.com/webhooks/quickstart.md) per creare una funzione endpoint webhook nel tuo linguaggio di programmazione.
- Utilizza la documentazione di riferimento dell’API Stripe per identificare gli [oggetti evento leggero](https://docs.stripe.com/api/v2/core/events/event-types.md) oppure [oggetti evento saliente](https://docs.stripe.com/api/events/object.md) che il gestore di webhook deve elaborare.

#### Endpoint di esempio

Questo frammento di codice è una funzione webhook configurata per verificare la presenza di eventi ricevuti da un account Stripe, gestire gli eventi e restituire risposte `200`. Fai riferimento al gestore eventi [salienti](https://docs.stripe.com/event-destinations.md#events-overview) quando utilizzi le risorse dell’API v1 e fai riferimento al gestore eventi [leggeri](https://docs.stripe.com/event-destinations.md#events-overview) quando utilizzi le risorse dell’API v2.

#### Gestore eventi salienti

Quando crei un gestore eventi salienti, utilizza la definizione dell’oggetto API impostata al momento dell’evento per la tua logica accedendo ai campi `data.object` dell’evento. È inoltre possibile recuperare la risorsa API dall’API Stripe per accedere alla definizione di oggetto più recente e aggiornata.

#### Ruby

```ruby
require 'json'

# Replace this endpoint secret with your unique endpoint secret key
# If you're testing with the CLI, run 'stripe listen' to find the secret key
# If you defined your endpoint using the API or the Dashboard, check your webhook settings for your endpoint secret: https://dashboard.stripe.com/webhooks
endpoint_secret = 'whsec_...';

# Using Sinatra
post '/webhook' do
  payload = request.body.read
  event = nil

  begin
    event = Stripe::Event.construct_from(
      JSON.parse(payload, symbolize_names: true)
    )
  rescue JSON::ParserError => e
    # Invalid payload
    status 400
    return
  end

  # Check that you have configured webhook signing
  if endpoint_secret
    # Retrieve the event by verifying the signature using the raw body and the endpoint secret
    signature = request.env['HTTP_STRIPE_SIGNATURE'];
    begin
      event = Stripe::Webhook.construct_event(
        payload, signature, endpoint_secret
      )
    rescue Stripe::SignatureVerificationError => e
      puts "⚠️  Webhook signature verification failed. #{e.message}"
      status 400
    end
  end

  # Handle the event
  case event.type
  when 'payment_intent.succeeded'
    payment_intent = event.data.object # contains a Stripe::PaymentIntent
    # Then define and call a method to handle the successful payment intent.
    # handle_payment_intent_succeeded(payment_intent)
  when 'payment_method.attached'
    payment_method = event.data.object # contains a Stripe::PaymentMethod
    # Then define and call a method to handle the successful attachment of a PaymentMethod.
    # handle_payment_method_attached(payment_method)
  # ... handle other event types
  else
    puts "Unhandled event type: #{event.type}"
  end

  status 200
end
```

#### Gestore eventi leggeri (Clover+)

Quando crei un gestore eventi leggeri, utilizza il metodo `fetchRelatedObject()` per recuperare l’ultima versione dell’oggetto associato all’evento. Gli eventi potrebbero contenere [dati aggiuntivi](https://docs.stripe.com/event-destinations.md#fetch-data) che puoi recuperare solo tramite il metodo di istanza `.fetchEvent()` su `EventNotification`. La forma esatta di tali dati dipende dal `type` di evento.

I tipi di evento devono essere disponibili al momento del rilascio per generare classi nella versione dell’SDK. Per gestire gli eventi per cui l’SDK non dispone di classi, utilizza la classe `UnknownEventNotification`.

#### Python

```python
import os
from stripe import StripeClient
from stripe.events import UnknownEventNotification

from flask import Flask, request, jsonify

app = Flask(__name__)
api_key = os.environ.get("STRIPE_API_KEY", "")
webhook_secret = os.environ.get("WEBHOOK_SECRET", "")

client = StripeClient(api_key)

@app.route("/webhook", methods=["POST"])
def webhook():
    webhook_body = request.data
    sig_header = request.headers.get("Stripe-Signature")

    try:
        event_notif = client.parse_event_notification(
            webhook_body, sig_header, webhook_secret
        )

        # type checkers will narrow the type based on the `type` property
        if event_notif.type == "v1.billing.meter.error_report_triggered":
            # in this block, event_notification is typed as
            # a V1BillingMeterErrorReportTriggeredEventNotification

            # there's basic info about the related object in the notification
            print(f"Meter w/ id {event_notif.related_object.id} had a problem")

            # or you can fetch the full object form the API for more details
            meter = event_notif.fetch_related_object()
            print(
                f"Meter {meter.display_name} ({meter.id}) had a problem"
            )

            # And you can always fetch the full event:
            event = event_notif.fetch_event()
            print(f"More info: {event.data.developer_message_summary}")

        elif event_notif.type == "v1.billing.meter.no_meter_found":
            # in this block, event_notification is typed as
            # a V1BillingMeterNoMeterFoundEventNotification

            # that class doesn't define `fetch_related_object` because the event
            # has no related object.
            # so this line would correctly give a type error:
            # meter = event_notif.fetch_related_object()

            # but fetching the event always works:
            event = event_notif.fetch_event()
            print(
                f"Err! No meter found: {event.data.developer_message_summary}"
            )

        # Events that were introduced after this SDK version release are
        # represented as `UnknownEventNotification`s.
        # They're valid, the SDK just doesn't have corresponding classes for them.
        # You must match on the "type" property instead.
        elif isinstance(event_notif, UnknownEventNotification):
            # these lines are optional, but will give you more accurate typing in this block
            from typing import cast

            event_notif = cast(UnknownEventNotification, event_notif)

            # continue matching on the type property
            # from this point on, the `related_object` property _may_ be None
            # (depending on the event type)
            if event_notif.type == "some.new.event":
                # if this event type has a related object, you can fetch it
                obj = event_notif.fetch_related_object()
                # otherwise, `obj` will just be `None`
                print(f"Related object: {obj}")

                # you can still fetch the full event, but it will be untyped
                event = event_notif.fetch_event()
                print(f"New event: {event.data}")  # type: ignore

        return jsonify(success=True), 200
    except Exception as e:
        return jsonify(error=str(e)), 400
```

#### Gestore di eventi leggeri (Acacia o Basil)

Quando crei un gestore eventi leggeri, utilizza il metodo `fetchRelatedObject()` per recuperare la versione più recente dell’oggetto associato all’evento. Gli eventi leggeri potrebbero contenere [ulteriori dati contestuali](https://docs.stripe.com/event-destinations.md#fetch-data) che puoi recuperare solo con l’API. Utilizza la chiamata `retrieve()` con l’ID dell’evento leggero per accedere a questi campi di payload aggiuntivi.

#### Python

```python
import os
from stripe import StripeClient
from stripe.events import V1BillingMeterErrorReportTriggeredEvent

from flask import Flask, request, jsonify

app = Flask(__name__)
api_key = os.environ.get('STRIPE_API_KEY')
webhook_secret = os.environ.get('WEBHOOK_SECRET')

client = StripeClient(api_key)

@app.route('/webhook', methods=['POST'])
def webhook():
    webhook_body = request.data
    sig_header = request.headers.get('Stripe-Signature')

try:
    thin_event = client.parse_thin_event(webhook_body, sig_header, webhook_secret)

    # Fetch the event data to understand the failure
    event = client.v2.core.events.retrieve(thin_event.id)
    if isinstance(event, V1BillingMeterErrorReportTriggeredEvent):
        meter = event.fetch_related_object()
        meter_id = meter.id

        # Record the failures and alert your team
        # Add your logic here

    return jsonify(success=True), 200
except Exception as e:
    return jsonify(error=str(e)), 400

if __name__ == '__main__':
    app.run(port=4242)
```

#### Usa `context`

#### Eventi istantanei

Questo frammento di codice è una funzione webhook configurata per verificare la presenza di eventi ricevuti, rilevare l’account di origine, se applicabile, gestire l’evento e restituire una risposta `200`.

#### Ruby

```ruby
require 'json'

# Using Sinatra
post '/webhook' do
  payload = request.body.read
  event = nil

  begin
    event = Stripe::Event.construct_from(
      JSON.parse(payload, symbolize_names: true)
    )
  rescue JSON::ParserError => e
    # Invalid payload
    status 400
    return
  end

  # Extract the context
  context = event.context

  # Define your API key variables (ideally loaded securely)
  ACCOUNT_123_API_KEY = "sk_test_123"
  ACCOUNT_456_API_KEY = "sk_test_456"

  account_api_keys = {
    "account_123" => ACCOUNT_123_API_KEY,
    "account_456" => ACCOUNT_456_API_KEY
  }

  api_key = account_api_keys[context]

  if api_key.nil?
    puts "No API key found for context: #{context}"
    status 400
    return
  end

  # Handle the event
  case event.type
  when 'customer.created'
    customer = event.data.object

    begin
      latest_customer = Stripe::Customer.retrieve(
        customer.id,
        { api_key: api_key }
      )
      handle_customer_created(latest_customer, context)
    rescue => e
      puts "Error retrieving customer: #{e.message}"
      status 500
      return
    end

  when 'payment_method.attached'
    payment_method = event.data.object

    begin
      latest_payment_method = Stripe::PaymentMethod.retrieve(
        payment_method.id,
        { api_key: api_key }
      )
      handle_payment_method_attached(latest_payment_method, context)
    rescue => e
      puts "Error retrieving payment method: #{e.message}"
      status 500
      return
    end

  else
    puts "Unhandled event type: #{event.type}"
  end

  status 200
end
```

#### Gestore eventi leggeri (Clover+)

Utilizza la proprietà `context` di `EventNotification` per identificare l’account per eventi all’interno della tua [organizzazione](https://docs.stripe.com/get-started/account/orgs.md). Devi impostare manualmente [l’intestazione Stripe-Context](https://docs.stripe.com/context.md) per tutte le chiamate API a eccezione di `.fetchRelatedObject()` and `.fetchEvent()`, che lo fanno automaticamente.

#### Python

```python
org_api_key = os.environ.get("STRIPE_API_KEY")
webhook_secret = os.environ.get("WEBHOOK_SECRET")
client = StripeClient(org_api_key)

# inside your webhook handler
event_notification = client.parse_event_notification(payload, sig_header, webhook_secret)

# uses `context` automatically
event_notification.fetch_event()

# pass context manually for other API requests
client.v1.invoices.list(stripe_context=event_notification.context)
```

#### Gestore di eventi leggeri (Acacia o Basil)

Questo frammento di codice è una funzione webhook configurata per ricevere gli eventi sottili di un’organizzazione, verificare la firma, determinare l’account di origine con il campo `context` e utilizzare la chiave API di quell’account per le successive chiamate API.

#### Python

```python
import os
from flask import Flask, request, jsonify
from stripe import StripeClient
from stripe.events import V1BillingMeterErrorReportTriggeredEvent

app = Flask(__name__)

org_api_key = os.environ.get("STRIPE_API_KEY")
webhook_secret = os.environ.get("WEBHOOK_SECRET")
client = StripeClient(org_api_key)

account_api_keys = {
    "account_123": os.environ.get("ACCOUNT_123_API_KEY"),
    "account_456": os.environ.get("ACCOUNT_456_API_KEY"),
}

@app.route("/webhook", methods=["POST"])
def webhook():
    payload = request.data
    sig_header = request.headers.get("Stripe-Signature")

    try:
        thin_event = client.parse_thin_event(payload, sig_header, webhook_secret)

        # Retrieve the event using the org client to inspect context
        event = client.v2.core.events.retrieve(thin_event.id)

        context = getattr(event, "context", None)
        if not context:
            return jsonify(error="Missing context"), 400

        account_key = account_api_keys.get(context)
        if not account_key:
            return jsonify(error="Unknown context"), 400

        account_client = StripeClient(account_key)
        full_event = account_client.v2.core.events.retrieve(thin_event.id)

        if isinstance(full_event, V1BillingMeterErrorReportTriggeredEvent):
            meter = full_event.fetch_related_object()
            meter_id = meter.id
            # Record the failures and alert your team
            # Add your logic here

        return jsonify(success=True), 200
    except Exception as e:
        return jsonify(error=str(e)), 400

if __name__ == "__main__":
    app.run(port=4242)
```

## Testa il gestore

Prima di passare alla modalità live con la funzione endpoint del webhook, ti consigliamo di verificare l’integrazione dell’applicazione. Puoi farlo configurando un listener locale per inviare eventi alla tua macchina locale e inviando eventi di test. Per eseguire il test, devi utilizzare la [CLI](https://docs.stripe.com/stripe-cli.md).

#### Inoltra gli eventi a un endpoint locale

Per inoltrare gli eventi all’endpoint locale, esegui il seguente comando con la [CLI](https://docs.stripe.com/stripe-cli.md) per configurare un listener locale. Il flag `--forward-to` invia tutti gli [eventi Stripe](https://docs.stripe.com/cli/trigger#trigger-event) in una [sandbox](https://docs.stripe.com/sandboxes.md) all’endpoint del webhook locale. Utilizza i comandi CLI appropriati riportati di seguito a seconda che tu utilizzi eventi [leggeri](https://docs.stripe.com/event-destinations.md#events-overview) o salienti.

#### Inoltrare gli eventi salienti

Utilizza il seguente comando per inoltrare gli [eventi salienti](https://docs.stripe.com/event-destinations.md#events-overview) al listener locale.

```bash
stripe listen --forward-to localhost:4242/webhook
```

#### Inoltrare eventi leggeri

Utilizza il seguente comando per inoltrare gli [eventi leggeri](https://docs.stripe.com/event-destinations.md#events-overview) al listener locale.

```bash
$ stripe listen --forward-thin-to localhost:4242/webhook --thin-events "*"
```

> Puoi anche eseguire `stripe listen` per vedere gli eventi in [Stripe Shell](https://docs.stripe.com/workbench/shell.md), anche se non potrai inoltrare gli eventi dalla shell al proprio endpoint locale.

Le configurazioni utili per aiutarti a eseguire i test con il tuo listener locale includono quanto segue:

- Per disabilitare la verifica del certificato HTTPS, usa il flag `--skip-verify`.
- Per inoltrare solo eventi specifici, utilizza il flag opzionale `--events` e specifica un elenco di eventi separati da virgola.

#### Inoltrare gli eventi salienti di destinazione

Utilizza il comando seguente per inoltrare gli eventi salienti di destinazione al listener locale.

```bash
stripe listen --events payment_intent.created,customer.created,payment_intent.succeeded,checkout.session.completed,payment_intent.payment_failed \
  --forward-to localhost:4242/webhook
```

#### Inoltrare eventi leggeri di destinazione

Utilizza il comando seguente per inoltrare gli eventi leggeri di destinazione al listener locale.

```bash
stripe listen --thin-events v1.billing.meter.error_report_triggered,v1.billing.meter.no_meter_found \
  --forward-thin-to localhost:4242/webhook
```

- Per inoltrare gli eventi all’endpoint del webhook locale dall’endpoint del webhook pubblico che hai già registrato su Stripe, utilizza il flag facoltativo `--load-from-webhooks-api`. Questo flag carica l’endpoint registrato, analizza il percorso e gli eventi registrati, poi aggiunge il percorso all’endpoint del webhook locale nel percorso `--forward-to path`.

#### Inoltrare gli eventi salienti da un endpoint del webhook pubblico

Usa il seguente comando per inoltrare gli eventi salienti da un endpoint del webhook pubblico al listener locale.

```bash
stripe listen --load-from-webhooks-api --forward-to localhost:4242/webhook
```

#### Inoltrare eventi leggeri da un endpoint di webhook pubblico

Usa il seguente comando per inoltrare gli eventi leggeri da un endpoint del webhook pubblico al listener locale.

```bash
stripe listen --load-from-webhooks-api --forward-thin-to localhost:4242/webhook
```

- Per controllare le firme dei webhook, utilizza `{{WEBHOOK_SIGNING_SECRET}}` dall’output iniziale del comando listen.

```output
Ready! Your webhook signing secret is '{{WEBHOOK_SIGNING_SECRET}}' (^C to quit)
```

#### Attivazione di eventi di test

Per inviare eventi di test, attiva un tipo di evento sottoscritto dalla destinazione dell’evento creando manualmente un oggetto nella Dashboard Stripe. Scopri come attivare gli eventi con [Stripe for Visual Studio Code](https://docs.stripe.com/stripe-vscode.md).

#### Attivare un evento saliente

Puoi utilizzare il seguente comando nella [Shell di Stripe](https://docs.stripe.com/workbench/shell.md) o nella [CLI di Stripe](https://docs.stripe.com/stripe-cli.md). Questo esempio attiva un evento `payment_intent.succeeded`:

```bash
stripe trigger payment_intent.succeeded
Running fixture for: payment_intent
Trigger succeeded! Check dashboard for event details.
```

#### Attivare un evento leggero

Puoi utilizzare il seguente comando nella [CLI di Stripe](https://docs.stripe.com/stripe-cli.md). Questo esempio attiva un evento `v1.billing.meter.error_report_triggered`:

```bash
stripe trigger v1.billing.meter.error_report_triggered
Setting up fixture for: list_billing_meters
Running fixture for: list_billing_meters
Setting up fixture for: billing_meter
Running fixture for: billing_meter
Setting up fixture for: list_billing_meters_after_creation
Running fixture for: list_billing_meters_after_creation
Setting up fixture for: billing_meter_event_session
Running fixture for: billing_meter_event_session
Setting up fixture for: create_billing_meter_event_stream
Running fixture for: create_billing_meter_event_stream
Trigger succeeded! Check dashboard for event details.
```

## Registra il tuo endpoint

Dopo aver testato la funzione dell’endpoint del webhook, utilizza l’[API](https://docs.stripe.com/api/v2/event-destinations.md) o la scheda **Webhook** in Workbench per registrare l’URL accessibile dell’endpoint del webhook in modo che Stripe sappia dove consegnare gli eventi. Puoi registrare fino a 16 endpoint del webhook con Stripe. Gli endpoint dei webhook registrati devono essere URL **HTTPS** accessibili pubblicamente.

#### Formato URL webhook

Il formato dell’URL per registrare un endpoint del webhook è:

```
https://<your-website>/<your-webhook-endpoint>
```

Ad esempio, se il dominio è `https://mycompanysite.com` e il percorso verso l’endpoint del webhook è `@app.route('/stripe_webhooks', methods=['POST'])`, specifica `https://mycompanysite.com/stripe_webhooks` come **URL dell’endpoint**.

#### Crea una destinazione di evento per il tuo endpoint del webhook

Crea la destinazione di un evento utilizzando Workbench nella Dashboard o a livello di codice con l’[API](https://docs.stripe.com/api/v2/event-destinations.md). Puoi registrare fino a 16 destinazioni degli eventi su ciascun account Stripe.

#### Dashboard

Per creare un nuovo endpoint del webhook nella Dashboard:

1. Apri la scheda [Webhook](https://dashboard.stripe.com/webhooks) in Workbench.
1. Fai clic su **Crea una destinazone dell’evento**.
1. Seleziona la destinazione da cui vuoi ricevere gli eventi. Stripe supporta due tipi di configurazioni: **Il tuo account** e [Account connessi](https://docs.stripe.com/connect.md). Seleziona **Account** per ascoltare gli eventi dal tuo account. Se hai creato un’[applicazione Connect](https://docs.stripe.com/connect.md) e vuoi ascoltare gli eventi dei tuoi account connessi, seleziona **Account connessi**.

> #### Ascolta gli eventi da un endpoint del webhook dell'organizzazione
> 
> Se crei un endpoint del webhook in un [account dell’organizzazione](https://docs.stripe.com/get-started/account/orgs.md), seleziona **Account** per ascoltare gli eventi degli account della tua organizzazione. Se hai [piattaforme Connect](https://docs.stripe.com/connect.md) come membri delle tue organizzazioni e vuoi ascoltare gli eventi di tutti gli account connessi delle piattaforme, seleziona **Account connessi**.

1. Seleziona la versione API per l’[oggetto di eventi](https://docs.stripe.com/api/events.md) che desideri utilizzare.
1. Seleziona i [tipi di evento](https://docs.stripe.com/api/events/types.md) che vuoi inviare a un endpoint del webhook.
1. Seleziona **Continua**, quindi scegli **Endpoint del webhook** come tipo di destinazione.
1. Clicca su **Continua**, quindi fornisci l’**URL dell’endpoint** e una descrizione facoltativa per il webhook.

#### API

Puoi creare una nuova destinazione evento che ti avvisi quando viene attivato un errore di convalida di [addebito a consumo](https://docs.stripe.com/billing/subscriptions/usage-based.md) utilizzando l’[API](https://docs.stripe.com/api/v2/event-destinations.md).

Se hai creato una [richiesta di Connect](https://docs.stripe.com/connect.md) e vuoi ascoltare i tuoi account connessi, utilizza il parametro [events_from](https://docs.stripe.com/api/v2/core/event-destinations/create.md#v2_create_event_destinations-events_from) e imposta il suo valore su `@accounts`. Per le destinazioni degli eventi dell’[organizzazione](https://docs.stripe.com/get-started/account/orgs.md), utilizza `@organization_members` per gli eventi degli account della tua organizzazione o `@organization_members/@accounts` per gli eventi degli account connessi di tutta la tua organizzazione.

```curl
curl -X POST https://api.stripe.com/v2/core/event_destinations \
  -H "Authorization: Bearer <<YOUR_SECRET_KEY>>" \
  -H "Stripe-Version: 2026-03-25.preview" \
  --json '{
    "name": "My event destination",
    "description": "This is my event destination, I like it a lot",
    "type": "webhook_endpoint",
    "event_payload": "thin",
    "enabled_events": [
        "v1.billing.meter.error_report_triggered"
    ],
    "webhook_endpoint": {
        "url": "https://example.com/my/webhook/endpoint"
    }
  }'
```

> [Workbench](https://docs.stripe.com/workbench.md) sostituisce la [Dashboard per sviluppatori](https://docs.stripe.com/development/dashboard.md) esistente. Se stai ancora utilizzando la Dashboard per sviluppatori, scopri come [creare un nuovo endpoint del webhook](https://docs.stripe.com/development/dashboard/webhooks.md).

## Proteggi il tuo endpoint

Dopo aver confermato che il webhook funziona come previsto, proteggi la connessione implementando le [pratiche ottimali del webhook](https://docs.stripe.com/webhooks.md#best-practices).

Proteggi l’integrazione assicurandoti che l’handler verifichi che tutte le richieste di webhook siano generate da Stripe. Puoi verificare le firme dei webhook utilizzando le nostre librerie ufficiali, oppure puoi verificarle manualmente.

#### Verifica con le librerie ufficiali (opzione consigliata)

### Verifica le firme del webhook con le librerie ufficiali

Per verificare le firme, ti consigliamo di utilizzare le nostre librerie ufficiali. Per eseguire la verifica, specifica il paylod dell’evento, l’intestazione `Stripe-Signature` e la chiave privata dell’endpoint. Se la verifica non va a buon fine, sarà visualizzato un messaggio di errore.

Se ricevi un errore di verifica della firma, consulta la nostra guida sulla [risoluzione dei problemi](https://docs.stripe.com/webhooks/signature.md).

> Stripe richiede il corpo raw della richiesta per eseguire la verifica della firma. Se stai utilizzando un framework, assicurati che non manipoli il corpo raw. Qualsiasi manipolazione del corpo raw della richiesta causa la non riuscita della verifica.

#### Ruby

```ruby

# Don't put any keys in code. See https://docs.stripe.com/keys-best-practices.
# Find your keys at https://dashboard.stripe.com/apikeys.
Stripe.api_key = '<<YOUR_SECRET_KEY>>'

require 'stripe'
require 'sinatra'

# If you are testing your webhook locally with the Stripe CLI you
# can find the endpoint's secret by running `stripe listen`
# Otherwise, find your endpoint's secret in your webhook settings in
# the Developer Dashboardendpoint_secret = 'whsec_...'

# Using the Sinatra framework
set :port, 4242

post '/my/webhook/url' do
  payload = request.body.readsig_header = request.env['HTTP_STRIPE_SIGNATURE']
  event = nil

  beginevent = Stripe::Webhook.construct_event(
      payload, sig_header, endpoint_secret
    )
  rescue JSON::ParserError => e
    # Invalid payload
    puts "Error parsing payload: #{e.message}"
    status 400
    return
  rescue Stripe::SignatureVerificationError => e# Invalid signature
    puts "Error verifying webhook signature: #{e.message}"
    status 400
    return
  end

  # Handle the event
  case event.type
  when 'payment_intent.succeeded'
    payment_intent = event.data.object # contains a Stripe::PaymentIntent
    puts 'PaymentIntent was successful!'
  when 'payment_method.attached'
    payment_method = event.data.object # contains a Stripe::PaymentMethod
    puts 'PaymentMethod was attached to a Customer!'
  # ... handle other event types
  else
    puts "Unhandled event type: #{event.type}"
  end

  status 200
end
```

#### Verifica manuale

### Verifica manualmente le firme dei webhook

Anche se è consigliabile utilizzare le nostre librerie ufficiali per verificare le firme degli eventi webhook, puoi creare una soluzione personalizzata seguendo questa procedura.

L’intestazione `Stripe-Signature` inclusa in ogni evento firmato contiene un timestamp e una o più firme che devi verificare. Il timestamp ha un prefisso `t=` e ogni firma ha un prefisso *scheme*. Gli schemi sono identificati da una `v` iniziale e un numero intero successivo. Attualmente, l’unico schema valido per le firme live è `v1`. Per facilitare i test, Stripe invia una firma aggiuntiva con uno schema `v0` fittizio per gli eventi di test.

```
Stripe-Signature:
t=1492774577,
v1=5257a869e7ecebeda32affa62cdca3fa51cad7e77a0e56ff536d0ce8e108d8bd,
v0=6ffbb59b2300aae63f272406069a9788598b792a944a07aba816edb039989a39
```

> Forniamo degli a capo per maggiore chiarezza, ma una vera intestazione `Stripe-Signature` è composta da un’unica riga.

Stripe genera le firme utilizzando una modalità di autenticazione dei messaggi basata su hash ([HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code)) con [SHA-256](https://en.wikipedia.org/wiki/SHA-2). Per impedire gli [attacchi basati su download](https://en.wikipedia.org/wiki/Downgrade_attack), ignora tutti gli schemi diversi da `v1`.

Puoi avere più firme con la stessa coppia schema-chiave privata quando [generi la chiave privata di un endpoint](https://docs.stripe.com/webhooks.md#roll-endpoint-secrets) e mantieni attiva la chiave privata precedente per massimo 24 ore. Durante questo periodo di tempo, l’endpoint ha più chiavi private attive e Stripe genera una firma per ognuna di esse.

Per creare una soluzione manuale per la verifica delle firme, è necessario completare i seguenti passaggi:

#### Fase 1: estrai il timestamp e le firme dall’intestazione

Per ottenere un elenco degli elementi, suddividi l’intestazione, utilizzando il carattere `,` come separatore. Poi suddividi ogni elemento, utilizzando il carattere `=` come separatore, per ottenere un prefisso e una coppia di valori.

Il valore del prefisso `t` corrisponde al timestamp e `v1` corrisponde alla firma (o alle firme). Puoi ignorare tutti gli altri elementi.

#### Fase 2: prepara la stringa `signed_payload`

La stringa `signed_payload` viene creata concatenando:

- Il timestamp (come stringa)
- Il carattere `.`
- Il payload JSON effettivo, ovvero il corpo della richiesta

#### Fase 3: determina la firma prevista

Calcola un HMAC con la funzione hash SHA256. Utilizza la chiave privata di firma dell’endpoint come chiave e la stringa `signed_payload` come messaggio.

#### Fase 4: confronta le firme

Confronta la firma (o le firme) nell’intestazione con la firma prevista. Per una corrispondenza di eguaglianza, calcola la differenza tra il timestamp corrente e quello ricevuto, poi decidi se la differenza rientra nella tolleranza.

Per proteggerti dagli attacchi temporizzati, utilizza un confronto di stringhe a tempo costante per confrontare la firma prevista con ogni firma ricevuta.

## Debug delle integrazioni del webhook

Durante la consegna di eventi all’endpoint del webhook, possono verificarsi diversi tipi di problemi:

- Stripe potrebbe non essere in grado di consegnare un evento all’endpoint del webhook.
- Potrebbe esserci un problema al certificato SSL dell’endpoint del webhook.
- La connettività di rete è intermittente.
- L’endpoint del webhook non riceve gli eventi che ti aspetti di ricevere.

### Visualizza le consegne dell’evento

Per visualizzare le consegne degli eventi, seleziona l’endpoint del webhook in **Webhook**, quindi seleziona la scheda **Eventi**. La scheda **Eventi** fornisce un elenco di eventi e indica se sono `Delivered`, `Pending`, o `Failed`. Fai clic su un evento per visualizzare i metadati, tra cui il codice di stato HTTP del tentativo di consegna e l’ora delle consegne future in sospeso.

Puoi utilizzare la [CLI di Stripe](https://docs.stripe.com/stripe-cli.md) anche per [ascoltare gli eventi](https://docs.stripe.com/webhooks.md#test-webhook) direttamente sul tuo terminale.

### Correggi i codici di stato HTTP

Quando per un evento viene visualizzato un codice di stato `200`, vuol dire che è avvenuta la consegna all’endpoint del webhook. Potresti anche ricevere un codice di stato diverso da `200`. Consulta la tabella riportata di seguito per un elenco dei codici di stato HTTP comuni e delle soluzioni consigliate.

| Stato webhook in sospeso        | Descrizione                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          | Correggi                                                                                                                                    |
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| (Connessione impossibile) ERR   | Non siamo in grado di stabilire una connessione con il server di destinazione.                                                                                                                                                                                                                                                                                                                                                                                                                                       | Assicurati che il tuo dominio host sia accessibile pubblicamente su Internet.                                                               |
| ERR (`302` o altro stato `3xx`) | Il server di destinazione ha tentato di reindirizzare la richiesta a un’altra posizione. Le risposte di reindirizzamento alle richieste di webhook sono considerate errori.                                                                                                                                                                                                                                                                                                                                          | Imposta la destinazione dell’endpoint del webhook sull’URL risolto dal reindirizzamento.                                                    |
| ERR (`400` o altro stato `4xx`) | Il server di destinazione non elabora la richiesta o non è in grado di farlo. Ciò può verificarsi quando il server rileva un errore (`400`), quando l’URL di destinazione ha restrizioni di accesso (`401`, `403`) o quando l’URL di destinazione non esiste (`404`).                                                                                                                                                                                                                                                | - Assicurati che il tuo endpoint sia accessibile pubblicamente su Internet.
  - Assicurati che il tuo endpoint accetti un metodo HTTP POST. |
| ERR (`500` o altro stato `5xx`) | Il server di destinazione ha rilevato un errore durante l’elaborazione della richiesta.                                                                                                                                                                                                                                                                                                                                                                                                                              | Esamina i registri della tua applicazione per capire perché restituisce un errore `500`.                                                    |
| (errore TLS) ERR                | Non è stato possibile stabilire una connessione con il server di destinazione. I problemi con il certificato SSL/TLS o un certificato intermedio nella catena di certificati del server di destinazione di solito causano questi errori. Stripe richiede *TLS* (TLS refers to the process of securely transmitting data between the client—the app or browser that your customer is using—and your server. This was originally performed using the SSL (Secure Sockets Layer) protocol) `v1.2` o versione superiore. | Esegui un [test del server SSL](https://www.ssllabs.com/ssltest/) per individuare i problemi che potrebbero aver causato l’errore.          |
| (Tempo scaduto) ERR             | Il server di destinazione ha impiegato troppo tempo per rispondere alla richiesta webhook.                                                                                                                                                                                                                                                                                                                                                                                                                           | Assicurati di rinviare la logica complessa e restituire immediatamente una risposta positiva nel codice di gestione del webhook.            |

## Comportamenti di consegna degli eventi

Questa sezione ti aiuta a comprendere i vari comportamenti da aspettarsi per quanto riguarda il modo in cui Stripe invia gli eventi all’endpoint del webhook.

### Tentativi automatici

Stripe tenta di consegnare gli eventi alla tua destinazione per un massimo di tre giorni con un ritardo di attesa esponenziale in modalità live. Visualizza la data del prossimo tentativo, se applicabile, nella scheda **Consegne evento** della destinazione dell’evento. Riproviamo le consegne degli eventi create in una sandbox tre volte nel corso di poche ore. Se la tua destinazione è stata disabilitata o eliminata durante un tentativo, impediamo futuri tentativi di quell’ evento. Tuttavia, se disabiliti e poi abiliti nuovamente la destinazione dell’evento prima che possiamo riprovare, vedrai comunque i tentativi futuri.

### Tentativi manuali

Sono disponibili due modi per riprovare a gestire manualmente gli eventi:

- Nella Dashboard di Stripe, fai clic su **Invia di nuovo** per un evento specifico. Funziona fino a 15 giorni dopo la creazione dell’evento.
- Con la [CLI di Stripe](https://docs.stripe.com/cli/events/resend), esegui il comando `stripe events resend <event_id> --webhook-endpoint=<endpoint_id>`. Funziona fino a 30 giorni dopo la creazione dell’evento.

Il reinvio manuale di un evento che in precedenza non era stato consegnato a un endpoint webhook non annulla il [comportamento di ripetizione automatica delle operazioni non riuscite](https://docs.stripe.com/webhooks.md#automatic-retries) di Stripe, anche se genera un codice di stato `2xx`. Scopri come [elaborare gli eventi webhook non consegnati](https://docs.stripe.com/webhooks/process-undelivered-events.md) per interrompere la ripetizione futura delle operazioni non riuscite.

### Ordine degli eventi

Stripe non garantisce la consegna degli eventi nell’ordine in cui sono stati generati. Ad esempio, la creazione di un abbonamento potrebbe generare i seguenti eventi:

- `customer.subscription.created`
- `invoice.created`
- `invoice.paid`
- `charge.created` (se esiste un addebito)

Assicurati che la destinazione dell’evento non dipenda dalla ricezione degli eventi in un ordine specifico. Preparati a gestire la consegna in modo appropriato. Puoi anche utilizzare l’API per recuperare eventuali oggetti mancanti. Ad esempio, se ricevi prima questo evento, puoi recuperare gli oggetti invoice, charge e subscription con le informazioni contenute in `invoice.paid`invoice.paid’.

### Controllo delle versioni dell’API

Quando si verifica l’evento, la versione dell’API nelle impostazioni dell’account determina la versione dell’API e quindi la struttura di un [evento](https://docs.stripe.com/api/events.md) inviato alla destinazione. Ad esempio, se il tuo account è impostato su una versione precedente dell’API, come la 2015-02-16, e modifichi la versione dell’API per una richiesta specifica con [controllo delle versioni](https://docs.stripe.com/api.md#versioning), l’oggetto [Event](https://docs.stripe.com/api/events.md) generato e inviato alla destinazione è ancora basato sulla versione dell’API 2015-02-16. Una volta creati, gli oggetti [Event](https://docs.stripe.com/api/events.md) non possono più essere modificati. Ad esempio, se aggiorni un addebito, quello originale rimane invariato. Di conseguenza, gli aggiornamenti successivi della versione dell’API dell’account non modificano in modo retroattivo gli oggetti [Event](https://docs.stripe.com/api/events.md) esistenti. Anche il recupero di un [Event](https://docs.stripe.com/api/events.md) precedente chiamando `/v1/events` con una versione più recente dell’API non influisce sulla struttura dell’evento ricevuto. Puoi impostare le destinazioni degli eventi di test sulla versione predefinita dell’API o su quella più recente dell’API. L’oggetto [Event](https://docs.stripe.com/api/events.md) inviato alla destinazione è strutturato per la versione specificata della destinazione dell’evento.

## Pratiche ottimali di utilizzo dei webhook

Rivedi queste pratiche ottimali per proteggere gli endpoint dei webhook e assicurarti che funzionino bene con la tua integrazione.

### Gestisci gli eventi duplicati

A volte gli endpoint dei webhook potrebbero ricevere lo stesso evento più di una volta. Per proteggerti dalla ricezione di eventi duplicati, registra gli [ID evento](https://docs.stripe.com/api/events/object.md#event_object-id) elaborati e poi non elaborare gli eventi già registrati.

In alcuni casi, vengono generati e inviati due oggetti Event separati. Per identificare questi duplicati, utilizza l’ID dell’oggetto in `data.object` e `event.type`.

### Ascolta solo i tipi di evento richiesti dalla tua integrazione

Configura gli endpoint dei webhook per ricevere solo i tipi di eventi richiesti dalla tua integrazione. L’ascolto di altri eventi (o di tutti gli eventi) appesantisce inutilmente il server e pertanto è sconsigliato.

È possibile [modificare gli eventi](https://docs.stripe.com/api/webhook_endpoints/update.md#update_webhook_endpoint-enabled_events) che un endpoint del webhook riceve attraverso la Dashboard o l’API.

### Gestire gli eventi in modo asincrono

Configura il gestore per elaborare i prossimi eventi con una coda asincrona. Se scegli di elaborare gli eventi in modo sincrono, potrebbero verificarsi problemi di scalabilità. Un forte aumento delle consegne di webhook (ad esempio, all’inizio del mese, quando tutti gli abbonamenti vengono rinnovati) può sovraccaricare gli host degli endpoint.

Le code asincrone consentono di elaborare gli eventi simultanei a una velocità supportata dal sistema.

### Percorso webhook esente dalla protezione CSRF

Se utilizzi Rails, Django o un altro framework web, il tuo sito potrebbe verificare automaticamente che ogni richiesta POST contenga un *token CSRF*. Questa importante misura di sicurezza consente di proteggere te e i tuoi utenti da eventuali tentativi di [falsificazione della richiesta tra siti](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_\(CSRF\)). Tuttavia, questa misura di sicurezza potrebbe anche impedire al sito di elaborare gli eventi legittimi. In tal caso, potrebbe essere necessario escludere il percorso dei webhook dalla protezione CSRF.

#### Rails

```ruby
class StripeController < ApplicationController
  # If your controller accepts requests other than Stripe webhooks,
  # you'll probably want to use `protect_from_forgery` to add CSRF
  # protection for your application. But don't forget to exempt
  # your webhook route!
  protect_from_forgery except: :webhook

  def webhook
    # Process webhook data in `params`
  end
end
```

### Ricevi eventi con un server HTTPS

Se utilizzi un URL HTTPS per l’endpoint del webhook (obbligatorio in modalità live), prima di inviare i dati del webhook Stripe verifica che la connessione al tuo server sia sicura. Per eseguire questa procedura, il tuo server deve essere configurato correttamente per supportare il protocollo HTTPS e deve disporre di un certificato valido. I webhook di Stripe supportano solo le versioni v1.2 e v1.3 di *TLS* (TLS refers to the process of securely transmitting data between the client—the app or browser that your customer is using—and your server. This was originally performed using the SSL (Secure Sockets Layer) protocol).

### Genera endpoint per la chiave privata della firma digitale in maniera periodica

La chiave privata utilizzata per verificare che gli eventi provengano da Stripe è modificabile nella scheda **Webhook** di Workbench. Per tenere al sicuro le chiavi private, ti consigliamo di revocarle (modificarle) periodicamente o nei casi in cui sospetti che siano state compromesse.

Per generare una chiave:

1. Fai clic su ciascun endpoint nella scheda degli **webhook** di Workbench per cui vuoi generare la chiave.
1. Vai al menu extra (⋯) e fai clic su **Revoca chiave privata**. Puoi scegliere di far scadere immediatamente la chiave privata corrente o ritardarne la scadenza per 24 ore per darti il tempo di aggiornare il codice di verifica sul server. In quel periodo di tempo sono attive più chiavi private per l’endpoint. Stripe genera una firma per chiave privata fino alla scadenza.

### Verifica che gli eventi siano inviati da Stripe

Senza verifica, un malintenzionato potrebbe inviare eventi webhook falsi al tuo endpoint per attivare azioni quali l’evasione di ordini, la concessione dell’accesso all’account o la modifica dei registri. Verifica sempre che gli eventi webhook provengano da Stripe prima di agire su di essi.

Utilizza entrambe le protezioni:

- **Elenco IP consentiti**: Stripe invia eventi webhook da un elenco predefinito di [indirizzi IP](https://docs.stripe.com/ips.md). Configura il tuo server o firewall in modo che accetti solo richieste webhook provenienti da questi indirizzi.
- **Verifica della firma**: Stripe firma ogni evento webhook includendo una firma nell’intestazione `Stripe-Signature`. Verifica questa firma utilizzando le nostre [librerie ufficiali](https://docs.stripe.com/webhooks.md#verify-official-libraries) o [manualmente](https://docs.stripe.com/webhooks.md#verify-manually) per confermare che l’evento non sia stato inviato o modificato da terzi.

La sezione seguente descrive come verificare le firme dei webhook:

1. Recuperando la chiave privata del tuo endpoint.
1. Verificando la firma.

#### Recuperare la chiave privata del tuo endpoint

Utilizza Workbench e vai alla scheda **Webhook** per visualizzare tutti gli endpoint. Seleziona un endpoint per il quale vuoi ricevere la chiave privata e poi fai clic sul pulsante **Fai clic per visualizzare**.

Stripe genera una chiave privata unica per ogni endpoint. Se utilizzi lo stesso endpoint per le [chiavi API di test e live](https://docs.stripe.com/keys.md#test-live-modes), la chiave privata è diversa per ogni modalità. Inoltre, se utilizzi più endpoint, per verificare le firme devi richiedere una chiave privata per ognuno di essi. Dopo questa configurazione, Stripe inizia a firmare ogni webhook che invia all’endpoint.

### Impedire gli attacchi di tipo replay

Un [attacco di tipo replay](https://en.wikipedia.org/wiki/Replay_attack) si verifica quando un utente malintenzionato intercetta un paylod valido e la sua firma e poi li ritrasmette. Per mitigare questi attacchi, Stripe include un timestamp nell’intestazione `Stripe-Signature`. Dato che il timestamp fa parte del payload firmato, viene anch’esso verificato dalla firma: quindi un utente malintenzionato non può modificare il timestamp senza invalidare la firma. Se la firma è valida ma il timestamp è troppo vecchio, puoi fare in modo che la tua applicazione rifiuti il payload.

Le nostre librerie hanno una tolleranza predefinita di 5 minuti tra il timestamp e l’ora corrente. Per modificarla, devi specificare un ulteriore parametro quando verifichi le firme. Utilizza il Network Time Protocol ([NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol)) per garantire che l’orologio del server sia preciso e sincronizzato con l’ora dei server di Stripe.

> Non utilizzare un valore di tolleranza `0`. L’utilizzo di un valore di tolleranza `0` disabilita completamente il controllo di frequenza.

Stripe genera il timestamp e la firma di ogni evento inviato all’endpoint. Se Stripe tenta di inviare di nuovo un evento, ad esempio perché in precedenza l’endpoint aveva risposto con un codice di stato non `2xx`, vengono generati una nuova firma e un nuovo timestamp per il nuovo tentativo di consegna.

### Restituisci rapidamente una risposta 2xx

L’[endpoint](https://docs.stripe.com/webhooks.md#example-endpoint) deve restituire rapidamente un codice di stato riuscito (`2xx`) prima che l’esecuzione di qualsiasi logica complessa possa causare un timeout. Ad esempio, è necessario restituire una risposta `200` prima che la fattura di un cliente venga aggiornata come pagata nel sistema contabile.

## See also

- [Inviare eventi ad Amazon EventBridge](https://docs.stripe.com/event-destinations/eventbridge.md)
- [Invia eventi alla Griglia di eventi di Azure](https://docs.stripe.com/event-destinations/eventgrid.md)
- [Elenco dei tipi di evento leggero](https://docs.stripe.com/api/v2/core/events/event-types.md)
- [Elenco dei tipi di eventi salienti](https://docs.stripe.com/api/events/.md)
- [Strumento interattivo per la creazione di endpoint del webhook](https://docs.stripe.com/webhooks/quickstart.md)