Guides
Start typing to search…

via API

API access is available on request, please contact [email protected] outlining your use case

Payment Link API

Shuttle provide 4 key APIs for creating and managing payment links:

  • POST /payment_links - Create a new payment link
  • GET /payment_links/{id} - Get a specific payment link
  • PUT /payment_links/{id} - Update an existing payment link
  • DELETE /payment_links/{id} - Delete a specific payment link

Handling Payment Link Notifications via Webhooks

Shuttle sends your applications notifications via Webhooks. Depending on your relationship with Shuttle, you can subscribe to payment link webhooks in multiple ways.

  • payment_link.webhook_url: Populate this field during payment_link creation to receive webhook notifications for this specific payment link
  • instance.webhook_url: Clients with access to update instances can enable webhooks for all events related to an instance (ie a specific Shuttle account)
  • application.webhook_url: SaaS Platform clients, can enable webhooks for all events related to all instances linked to their application.

When using a workflow automation tool, webhooks are configured at the instance.webhook_url level, as such you will recieve all webhooks for that account (including non payment link webhooks) and should filter for those you want using action and state fields.

Webhook Security

Webhooks are sent from a secure server and contain the following security measures:

  • Webhooks do not contain any sensitive information, just object references. You must fetch them via the API using your API credentials.
  • Webhooks must be to a HTTPS target on port 443.
  • All webhooks will come from one of the following IP addresses:
    • 52.51.86.26
    • 54.229.12.118
    • 54.76.31.104
    • 34.252.246.134

Webhook Retry Policy

A webhook that returns HTTP 200 or HTTP 204 will be considered successful, any other status will be deemed a failure.

By default webhooks are not retried unless you activate a retry policy. You can activate a webhook retry policy using the following syntax. Each retry will typically happen after 1 minute.

  • |: sets the number of attempts, eg https://targetA/url|3 (attempt 3 times)
  • >: failover to a second URL, eg https://targetA/url>https://targetB/url (attempt targetA, then attempt targetB)
  • ,: send a webhook to multiple destinations eg https://targetA/url,https://targetB/url (sent to targetA AND targetB)

Examples:

  • https://targetA/url - send the webhook to targetA
  • https://targetA/url|2 - send the webhook to targetA, if a HTTP 200 result not returned, try again 1 minute later
  • https://targetA/url|120 - send the webhook to targetA every minute until successful for 2 hours
  • https://targetA/url>https://targetB/url - send the webhook to targetA, if fail send to targetB after 1 minute
  • https://targetA/url>https://targetB/url>https://targetC/url - send the webhook to targetA, then targetB, then targetC (etc)
  • https://targetA/url|60>https://targetB/url|5 - send the webhook to targetA every minute for an hour then failover to targetB for 5 minutes
  • https://targetA/url,https://targetB/url - send the webhook to targetA and targetB
  • https://targetA/url|60,https://targetB/url|60 - send the webhook to targetA for up to an hour and targetB for up to an hour

Note: Retries are DISABLED in the sandbox environment.

Updated 11 days ago