NAV
curl

Introduction

Welcome to the Reepay API documentation.

The Reepay API is REST based and designed to have predictable resource-oriented URLs and to use HTTP response codes to indicate API errors.

The Reepay API is formally specified using a Swagger specification. Swagger is a specification standard surrounded by an ecosystem of tools, which includes front-end user interfaces and code generation libraries. We highly encourage you to have a look at the code generation library which can generate client code for various programming languages.

Reepay API Swagger resources:

The specification user-interface allows testing of resource operations using your private API key.

A project demonstrating uses of the Reepay API are hosted on Github. The project is under constant development and contributions are welcomed. The project has a Wiki describing some common use cases.

Authentication

Authentication to the Reepay API is done using a private API key. All API requests must be made over HTTPS. Calls made over plain HTTP will fail. Most requests require authentication.

API key authentication is done by providing one of your private API keys in the request. You can manage your private API keys from your account. You can have multiple API keys active at one time. Your API keys carry many privileges, so be sure to keep them secret!

The API key must be provided as the HTTP Basic Auth username.No password needs to be provided. HTTP Basic Auth is performed by sending an Authorization header with value Basic base64('<privatekey>:'). E.g. for private key

priv_12051dfac75143fc827cf63a87f46df3

the value will be

base64('priv_12051dfac75143fc827cf63a87f46df3:') = cHJpdl8xMjA1MWRmYWM3NTE0M2ZjODI3Y2Y2M2E4N2Y0NmRmMzo=

and the complete header will be

Authorization: Basic cHJpdl8xMjA1MWRmYWM3NTE0M2ZjODI3Y2Y2M2E4N2Y0NmRmMzo=

To test base64 encoding the following site can be used www.base64decode.org

Reepay also supports token based authentication where a token is obtained by a login with username and password. This solution can be used if you wish to build an administration solution using the credentials stored at Reepay. Contact Reepay for more information if this is relevant for you.

Response Data

All responses from the Reepay API will be in JSON. All responses will contain a unique request identifier in the HTTP headers with name Request-Id. The request-id allows Reepay to find requests in cases where troubleshooting is necessary.

Request data

As POST and PUT data the Reepay API accepts application/json content-type. The content-type must be defined in the HTTP header of requests.

Errors

Reepay uses conventional HTTP response codes to indicate success or failure of an API request. In general, codes in the 2xx range indicate success, codes in the 4xx range indicate an error that resulted from the provided information, and codes in the 5xx range indicate an error at Reepay or external systems used by Reepay.

HTTP Status Code Summary

HTTP code Description
200 - OK Everything worked as expected.
400 - Bad Request Illegal operation on a resource
401 - Unauthorized No valid authentication provided
403 - Forbidden Authentication given but not authorized to resource operation
404 - Not Found The requested resource and referenced resources does not exist
405 - Method Not Allowed The used HTTP method is not allowed on the resource
422 - Unprocessable Entity The request could not be interpreted, often missing a required parameter or wrongly formatted parameters
500-504 - Server Errors An internal error occurred on Reepay’s end

Error response

All non successful 2xx responses will return a generic JSON error response with the following parameters.

{
  "code" : 13,
  "error" : "Subscription expired",
  "http_reason" : "Bad Request",
  "http_status" : 400,
  "path" : "/v1/subscription/WHBBv/expire",
  "timestamp" : "2015-06-12T06:38:33.876+0000",
  "request-id" : "de03e86d0a6d44359b249340f967ddc9",
  "transaction_error" : "credit_card_expired"
}
Parameter Type Description
code integer Reepay API error code. See full list of error codes here
error string Short error message
message string Optional clarifying error message
http_status integer HTTP status code of the error (same as the HTTP response)
http_reason string HTTP reason of the error (same as the HTTP response)
path string The path generating the error response
timestamp string Date when the error occurred. In ISO-8601 extended offset date-time format.
request-id string Unique request id for the failed request.
transaction_error  string Optional transaction error in the case the request involved transaction processing. See table below with possible transaction errors.

Example on the right.

Transaction errors

For requests that involves transaction processing the error response will contain a transaction error in the case transaction processing failed. Three error codes 66 (refund failed), 77 (transaction declined) and 78 (transaction processing error) will return a transaction error. Transaction errors is also given on failed transactions for invoices, charges and refunds.

Transaction errors can be divided into two three categories, hard declines, soft declines and processing errors.

The following transaction errors can be returned.

Hard declines

Irrecoverable card errors. The card is declined and future attempts will fail.

Transaction error Description
credit_card_expired Credit card expired
declined_by_acquirer Transaction declined by acquirer for some reason
credit_card_lost_or_stolen Credit card lost or stolen
credit_card_suspected_fraud Credit card suspected fraud
refund_amount_too_high The tried refund amount is too high
authorization_expired Settle failed because the authorization has expired
authorization_amount_exceeded Settle failed because requested amount exceeded authorized amount
authorization_voided Settle failed because authorization has been voided

Soft declines

Possible recoverable errors. The card or settle of authorization is declined but future attempts may succeed. E.g. insufficient funds on card.

Transaction error Description
insufficient_funds Valid payment method but insufficient funds to complete transaction
settle_blocked Settle of authorization blocked by acquirer or payment gateway

Processing errors

Errors in the processing chain from Reepay to the acquirer.

Transaction error Description
acquirer_communication_error Communication with acquirer failed
acquirer_error Error at the acquirer or payment gateway
acquirer_integration_error There is an error in the integration to the acquirer
acquirer_authentication_error Provided authentication credentials are not valid
acquirer_configuration_error Error in the configuration of the acquirer or payment gateway account
acquirer_rejected_error Acquirer rejected this specific transaction. E.g. amount too low or too high.

Searching and pagination

Most top-level Reepay API resources have support for bulk fetches — “list” API methods. For instance you can list invoices, list customers, and list subscriptions. These list API methods share a common structure.

Reepay utilizes page-based pagination, using the query parameters page and size. Pass page to dictate what page you want to show and size to dictate how many items you want per page. Each individual resource will have resource specific filtering and sorting options.

The generic response is either a page with total number and elements, or a slice lacking these two parameters. Slicing is used for optimization reasons when counting the total number of elements can be too expensive. The generic response contains the following parameters:

{
    "page": 50,
    "size": 50,
    "count": 50,
    "content": [ ... ],
    "total_elements": 500,
    "total_pages": 10,
    "search": "customer:cust0002",
    "sort": "-created"
}
Parameter Type Description
page integer Number of current page in paginated list
size integer Page size used
count integer Number of elements in current page
content array List of objects for current page
total_elements integer Total number of elements in paginated list (not included for sclices)
total_pages integer Total number of pages in paginated list (not included for sclices)
search string Optional used search expression (see below)
sort string Optional used sorting expression (see below)

Example on the right.

For slicing a next page can be requested as long count = size.

Search expression

Most bulk fetches features an option to search and sort. Searching is done using search expressions. A search expression is as a comma separated list of search criteria. A search criteria is on the form:

<parameter_name><operator><value>

The following operators can be used:

Operator Description
: Equals. The parameter value must match value.
; Contains. The value must be contained in the parameter value. For strings case-insensitivity comparison is used.
< Lees than
> Greater than

Example of a search expression for customers:

handle;cust,country:DK

The customer handle must contain cust and the country of the customer must equal DK.

Sort expression

Sorting is done using sorting expressions. A sorting expression is a comma separated list of orders. An order is a parameter name and an optional direction. The order is on the form:

<direction><parameter_name>

The direction is optional and can be either + (ascending) or - (descending). Example for the customer resource.

-handle,created

The customers are first sorted descending by handle and secondly ascending by created.

Webhooks

Reepay can issue webhooks that can be used to keep your system in sync and to take customized actions. Webhooks requires you to have a publicly accessible web server listening on port 80 (HTTP) or 443 (HTTPS). These are the only ports supported. Webhooks can be configured with multiple URL’s to support a redundant setup where the same webhook is sent to multiple URL’s. See webhook settings. Below some rules and best practices regarding webhooks:

Webhook content

The webhook content is in JSON and contains the following parameters (example on the right):

{
    "id": "8ab4b56439944e62ababca7954355578",
    "event_id": "680bd8055b5c444bb467dcb731c65bf9",
    "event_type": "invoice_settled",
    "timestamp": "2015-06-25T12:10:00.64Z",
    "signature": "7a591eddc400af4c8a64ff551ff90b37d79471bd2c9a5a2fcd4ed6944f39cb09",
    "customer": "OVAFIJ",
    "subscription": "sub001",
    "invoice": "23688c2c758040f9bc6cdee0fad6cc77",
    "credit_note" : "a26c1bf5f656f489f295d0c4748dd003",
    "transaction" : "28b1af53d7ecd1c487292402a908e2b3"
}
Parameter Description
id Unique id for webhook. If multiple URL’s are used each request will have different id’s but same event_id.
event_id Id of event triggering webhook (see events).
event_type The event type (see below and events).
timestamp Timestamp in ISO-8601 when the webhook was triggered.
signature Signature to verify the authenticity of the webhook. See below.
customer (Optional) Customer handle. Included if event relates to a customer resource.
subscription (Optional) Subscription handle. Included if event relates to a subscription resource.
invoice (Optional) Invoice id or handle if provided. Included if event relates to an invoice resource.
credit_note (Optional) Credit note id. Included if the event relates to an invoice refund.
transaction (Optional) For invoice events a transaction id is included if the event was result of a transaction, e.g. a card settle transaction. The transaction id the same as refund id for refunds.

The signature is calculated as follows:

signature = hexencode(hmac_sha_256(webhook_secret, timestamp + id))

That is

The same calculation can be done in the receiving end, allowing authentication of the webhook. The webhook secret is defined in the webhook settings.

Webhook event types

Webhooks are triggered by events. See event for a complete list if event types and their description.

Webhook retries

Reepay will retry failing webhooks using the following retry intervals: 10 min - 20 min - 30 min - 60 min and then every 3 hours for a week.

Webhook alerting

In the Reepay administration under Webhook configuration, alerting can be enabled that will send emails to a number of recipients if webhooks fail. An alert will be sent at most once for each failing webhook. To limit the amount of alerts, at most one email will be sent every 30 minutes per account.

Testing

Testing different scenarios in Reepay can be done using our Test Payment Gateway and a number of test cards. The test cards are fixed but a number of predefined CVV codes and amounts can be used to trigger different scenarios. Any expiration date can be used as long as it is the current month or in the future.

Test cards

Type Id Number
Visa visa 4111 1111 1111 1111
Visa-DK visa_dk 4571 9940 0006 2336
Dankort dankort 5019 1000 0000 0006
Visa Electron visa_elec 4000 1234 5678 9017
Mastercard mc 5500 0000 0000 0004
American Express amex 3400 000000 00009
JCB jcb 3530 1113 3330 0000
Maestro maestro 6759 0000 0000 0000
Laser laser 6771 9856 3094 1108
Diners diners 3000 0000 0000 04
Discover discover 6011 1111 1111 1117
China Union Pay china_union_pay 6240 0086 3140 1148

Token create errors

Errors in the authorization process of adding a card payment method can triggered by the following CVV codes.

CVV Scenario
001 The credit card is declined with due to credit card expired
002 The credit card is declined by the acquirer
003 The credit card is declined due to insufficient funds
004 The authorization is declined due to errors at the acquirer
005 The authorization is declined due to communication problems with the acquirer
006 The authorization is declined due to communication problems with the acquirer (60 second processing time)

Subsequent subscription billing errors

All CVV codes, except the ones above, will result in a successful card authorization. The CVV codes below can be used to trigger different scenarios for subsequent payments. Declines are separated into recoverable and irrecoverable declines. Irrecoverable declines indicates that a payment will never be possible for the card again, e.g. an expired or blocked card. Recoverable declines indicates that successful payments for the card could be possible in the future. This could for example be due to insufficient funds. Reepay will start dunning for recoverable declines, but will regularly try to process payments using the card, as long as a new payment method has not been added.

CVV Scenario
100 The first payment is declined with an irrecoverable error (credit card expired)
101 The first payment is declined with an irrecoverable error (declined by acquirer)
102 The first payment is declined with an recoverable error (insufficient funds)
200 The second payment is declined with an irrecoverable error (credit card expired)
201 The second payment is declined with an irrecoverable error (declined by acquirer)
202 The second payment is declined with an recoverable error (insufficient funds)
300 With a probability of 50% the payment is declined with an irrecoverable error (credit card expired)
301 With a probability of 50% the payment is declined with an irrecoverable error (declined by acquirer)
302 With a probability of 50% the payment is declined with an recoverable error (insufficient funds)

Charging errors

To trigger errors in the process of creating charges and settling authorized charges the cvv 888 can be used in combination with a number of amounts. E.g. a successful authorization can be performed and then a specific amount can be used for the settlement that will result in an error. The table below shows the amounts to be used with cvv 888 to trigger errors.

Amount Error state Error code
1000 success
1001 processing_error acquirer_communication_error
1002 processing_error acquirer_error
1003 processing_error acquirer_integration_error
1004 processing_error acquirer_authentication_error
1005 processing_error acquirer_configuration_error
1006 processing_error acquirer_rejected_error
2001 soft_declined insufficient_funds
2002 soft_declined settle_blocked
3001 hard_declined credit_card_expired
3002 hard_declined declined_by_acquirer
3003 hard_declined credit_card_lost_or_stolen
3004 hard_declined credit_card_suspected_fraud
3005 hard_declined authorization_expired
3006 hard_declined authorization_amount_exceeded
3007 hard_declined authorization_voided

Account

When using Reepay, you have the ability to have multiple accounts.

Use multiple accounts when:

An Example:

The company “Awesome Fitness” have fitness centers in the UK and Denmark, in both countries they have a head office.

They want to ensure customers will be billed in local currency and are billed from the local head office. Furthermore they want to limit access for their support and finance employees to only relevant data.

Therefore they add two accounts to their organization, one for UK and one for DK.

Now, when adding customers and subscription they can specify the account by it’s API Key/Token. (remember to generate an API key for your account after creating)

Values like address,city,locale, phone,website,logo will affect the information your customers receive in E-mails and on hosted pages from Reepay. The currency value will decide the currency for the accounts plans and basically what currency you customers will pay in.

When granting access to new users “Awesome Fitness” can choose to limit access to one account or both.

You can also manage your accounts in our admin.

The Account object

[Swagger:definition:json:Account]

[Swagger:definition:table:Account]

Get account

[Swagger:request:curl:getCurrentAccount]

The above command returns JSON structured like this

[Swagger:response:json:getCurrentAccount]

Get the account object for the current authentication. E.g. private API key.

HTTP Request

GET https://api.reepay.com/v1/account

Returns

Returns the current authenticated Account.

Update account

[Swagger:request:curl:updateAccountJson]

The above command returns JSON structured like this

[Swagger:response:json:updateAccountJson]

Update account by setting the values of the parameters passed, the account is found from the used API key/token. Any parameters not provided will be deleted.

HTTP Request

PUT https://api.reepay.com/v1/account

[Swagger:request:table:updateAccountJson]

Returns

Returns the updated Account object.

Get mail settings

[Swagger:request:curl:getMailSettings]

The above command returns JSON structured like this

[Swagger:response:json:getMailSettings]

Get mail settings for account.

HTTP Request

GET https://api.reepay.com/v1/account/mail_settings

Returns

Returns the MailSettings for the current Account.

Update mail settings

[Swagger:request:curl:updateMailSettingsJson]

The above command returns JSON structured like this

[Swagger:response:json:updateMailSettingsJson]

Update mail settings for account.

HTTP Request

PUT https://api.reepay.com/v1/account/mail_settings

[Swagger:request:table:updateMailSettingsJson]

Returns

Returns the updated MailSettings for the current Account.

Get discount settings

[Swagger:request:curl:getDiscountSettings]

The above command returns JSON structured like this

[Swagger:response:json:getDiscountSettings]

Get discount settings for account.

HTTP Request

GET https://api.reepay.com/v1/account/discount_settings

Returns

Returns the DiscountSettings for the current Account.

Update discount settings

[Swagger:request:curl:updateDiscountSettings]

The above command returns JSON structured like this

[Swagger:response:json:updateDiscountSettings]

Update discount settings for account.

HTTP Request

PUT https://api.reepay.com/v1/account/discount_settings

[Swagger:request:table:updateDiscountSettings]

Returns

Returns the updated DiscountSettings for the current Account.

Get list of private keys

[Swagger:request:curl:getPrivateKeys]

The above command returns JSON structured like this

[Swagger:response:json:getPrivateKeys]

Get private keys for account.

HTTP Request

GET https://api.reepay.com/v1/account/privkey

[Swagger:response:table:getPrivateKeys]

Create private key

[Swagger:request:curl:createPrivateKey]

The above command returns JSON structured like this

[Swagger:response:json:createPrivateKey]

Use an API key to create more API keys for your current account. The current account is decided from the API key you are using.

To create the first API key you must go to our admin in the API key section.

HTTP Request

POST https://api.reepay.com/v1/account/privkey

Returns

[Swagger:response:table:createPrivateKey]

Expire private key

[Swagger:request:curl:expirePrivateKey]

Expire a private key by, remember to use a private key from the same account as the one you are about to expire. You can expire the one you are using as authentication.

HTTP Request

POST https://api.reepay.com/v1/account/privkey/{key}/expire

[Swagger:request:table:expirePrivateKey]

Get list of public keys

[Swagger:request:curl:getPublicKeys]

The above command returns JSON structured like this

[Swagger:response:json:getPublicKeys]

Get public keys for account.

HTTP Request

GET https://api.reepay.com/v1/account/pubkey

[Swagger:response:table:getPublicKeys]

Create public key

[Swagger:request:curl:createPublicKey]

The above command returns JSON structured like this

[Swagger:response:json:createPublicKey]

Create more public keys for the current account.

HTTP Request

POST https://api.reepay.com/v1/account/pubkey

Returns

[Swagger:response:table:createPublicKey]

Expire public key

[Swagger:request:curl:expirePublicKey]

Expire a public key.

HTTP Request

POST https://api.reepay.com/v1/account/pubkey/{key}/expire

[Swagger:request:table:expirePublicKey]

Get webhook settings

[Swagger:request:curl:getWebhookSettings]

The above command returns JSON structured like this

[Swagger:response:json:getWebhookSettings]

Get webhook settings. See webhook documentation in introduction. The webhook settings consist of:

HTTP Request

GET https://api.reepay.com/v1/account/webhook_settings

Returns

[Swagger:response:table:getWebhookSettings]

Update webhook settings

[Swagger:request:curl:updateWebhookSettingsJson]

The above command returns JSON structured like this

[Swagger:response:json:updateWebhookSettingsJson]

Update webhook settings. Webhook secret is left unchanged and must separately be re-generated. See below.

HTTP Request

PUT https://api.reepay.com/v1/account/webhook_settings

[Swagger:request:table:updateWebhookSettingsJson]

Returns

Returns the updated WebhookSettings

Generate new webhook secret

[Swagger:request:curl:generateWebhookSecret]

The above command returns JSON structured like this

[Swagger:response:json:generateWebhookSecret]

Generate a new webhook secret.

HTTP Request

POST https://api.reepay.com/v1/account/webhook_settings/secret

Returns

Returns the WebhookSettings object, containing the new secret.

Organisation

Organisation resource for managing organisation settings.

The Organisation object

[Swagger:definition:json:Organisation]

[Swagger:definition:table:Organisation]

Get organisation

[Swagger:request:curl:getOrganisation]

The above command returns JSON structured like this

[Swagger:response:json:getOrganisation]

Get organisation for authenticated account.

HTTP Request

GET https://api.reepay.com/v1/organisation

Return

Returns an Organisation object.

Update organisation

[Swagger:request:curl:update]

The above command returns JSON structured like this

[Swagger:response:json:update]

Update organisation.

HTTP Request

PUT https://api.reepay.com/v1/organisation

[Swagger:request:table:update]

Return

Returns an Organisation object.

Plan

A subscription plan defines subscription product information, subscription terms, and when and how much to charge for a subscription. An unlimited number of plans can be defined for an account.

Subscription plans are versioned so changes (superseding) results in a new version of the plan. It can be chosen to either let subscriptions stay on the old version of the plan, or to change for all subscriptions using the plan.

The Plan object

[Swagger:definition:json:Plan]

[Swagger:definition:table:Plan]

Get list of plans

[Swagger:request:curl:getPlansList]

The above command returns JSON structured like this

[Swagger:response:json:getPlansList]

Returns a list of your plans, you can specify to only get active plans.

HTTP Request

GET https://api.reepay.com/v1/plan?only_active={only_active}

Query Parameters

[Swagger:request:table:getPlansList]

Return

Returns an array of Plan objects.

Create plan

[Swagger:request:curl:createPlanJson]

The above command returns JSON structured like this

[Swagger:response:json:createPlanJson]

You can create plans easily via the plan management page of the Reepay dashboard. Plan creation is also accessible via the API if you need to create plans from you own system.

HTTP Request

POST https://api.reepay.com/v1/plan

[Swagger:request:table:createPlanJson]

Return

Returns a Plan object.

Get list of plan versions

[Swagger:request:curl:getPlans]

The above command returns JSON structured like this

[Swagger:response:json:getPlans]

You can get a list of all version of a plan. If you Supersede a plan to update things like amount, then Reepay will generate a new version of the plan. You can keep current subscriptions on the old plan version.

Using this you can get a full list of all versions of a plan.

HTTP Request

GET https://api.reepay.com/v1/plan/{handle}

[Swagger:request:table:getPlans]

Return

Returns an array of Plan objects.

Supersede plan

[Swagger:request:curl:supersedePlanJson]

The above command returns JSON structured like this

[Swagger:response:json:supersedePlanJson]

If you want to update a plans amount and information that has a big effect on the subscriptions you must supersede the old plan, which means Reepay will create a new version of the plan. For this you use “supersede plan” instead of “update plan”.

Beside the normal plan features you must decide what will happen with the current subscriptions that uses the plan. For this you use supersede_mode, that can be set to the following modes:

Mode Description
no_sub_update Using this all subscriptions will still use the old version of the plan.
scheduled_sub_update This will update all subscriptions to use the new version after the current billing period ends.
instant_sub_update This will update all subscriptions using the plan to the new version instantly.

HTTP Request

POST https://api.reepay.com/v1/plan/{handle}

[Swagger:request:table:supersedePlanJson]

Return

Returns a Plan object.

Update plan

[Swagger:request:curl:updatePlanJson]

The above command returns JSON structured like this

[Swagger:response:json:updatePlanJson]

Use this to update a plan. I you want to update major things like amount, please use Supersede instead.

HTTP Request

PUT https://api.reepay.com/v1/plan/{handle}

[Swagger:request:table:updatePlanJson]

Return

Returns a Plan object.

Delete plan

[Swagger:request:curl:deletePlan]

The above command returns JSON structured like this

[Swagger:response:json:deletePlan]

You can delete plans via the plan management page of the Reepay dashboard. However, deleting a plan does not affect any current subscribers to the plan; it merely means that new subscribers can’t be added to that plan. You can also delete plans via the API.

HTTP Request

DELETE https://api.reepay.com/v1/plan/{handle}

[Swagger:request:table:deletePlan]

Return

Returns a Plan object.

Get plan

[Swagger:request:curl:getCurrentPlan]

The above command returns JSON structured like this

[Swagger:response:json:getCurrentPlan]

Retrieves current version of the plan with the given handle.

HTTP Request

GET https://api.reepay.com/v1/plan/{handle}/current

[Swagger:request:table:getCurrentPlan]

Return

Returns a Plan object.

Get plan version

[Swagger:request:curl:getPlan]

The above command returns JSON structured like this

[Swagger:response:json:getPlan]

Retrieves a version of the plan with the given handle.

HTTP Request

GET https://api.reepay.com/v1/plan/{handle}/{version}

[Swagger:request:table:getPlan]

Return

Returns a Plan object.

Dunning plan

For an account a number of dunning plans can be configured. An account must have at least one dunning plan. One of the dunning plans must be defined as the default dunning plan.

A dunning plan is a plan for the dunning process an invoice goes into if the settlement of an invoice fails. A dunning plan consists of a schedule as a list of intervals in days, and a final action for the subscription if the dunning process fails. The final action is either to do nothing, or to expire the subscription.

The dunning process proceeds as follows:

For a schedule with only one interval a single notification is sent followed by a wait and then the final action is taken if the invoice is not settled before the interval end. If an empty schedule is used, no notification is sent and the final action is taken immediately.

The Dunning plan object

[Swagger:definition:json:DunningPlan]

[Swagger:definition:table:DunningPlan]

Get list of dunning plans

[Swagger:request:curl:getDunningPlans]

The above command returns JSON structured like this

[Swagger:response:json:getDunningPlans]

Get list of dunning plans

HTTP Request

GET https://api.reepay.com/v1/dunning_plan

Return

Returns an array of Dunning Plan objects.

Create dunning plan

[Swagger:request:curl:createDunningPlanJson]

The above command returns JSON structured like this

[Swagger:response:json:createDunningPlanJson]

Create a new dunning plan.

HTTP Request

POST https://api.reepay.com/v1/dunning_plan

[Swagger:request:table:createDunningPlanJson]

Return

Returns a Dunning Plan object.

Get dunning plan

[Swagger:request:curl:getDunningPlan]

The above command returns JSON structured like this

[Swagger:response:json:getDunningPlan]

Get dunning plan by handle.

HTTP Request

GET https://api.reepay.com/v1/dunning_plan/{handle}

[Swagger:request:table:getDunningPlan]

Return

Returns a Dunning Plan object.

Update dunning plan

[Swagger:request:curl:updateJson]

The above command returns JSON structured like this

[Swagger:response:json:updateJson]

Update dunning plan. If currently default plan is made non-default, the oldest plan will be made new default.

HTTP Request

PUT https://api.reepay.com/v1/dunning_plan/{handle}

[Swagger:request:table:updateJson]

Return

Returns a Dunning Plan object.

Delete dunning plan

[Swagger:request:curl:deleteDunningPlan]

The above command returns JSON structured like this

[Swagger:response:json:deleteDunningPlan]

Delete dunning plan. A dunning plan can only be deleted if no subscription plans use the dunning plan, and only if the dunning plan is not the only remaining plan. If the deleted plan is default, the oldest plan will be made new default.

HTTP Request

DELETE https://api.reepay.com/v1/dunning_plan/{handle}

[Swagger:request:table:deleteDunningPlan]

Return

Returns a Dunning Plan object.

Customer

The customer object is core to managing your customers inside of Reepay. The customer object stores the entire Reepay history of your customer and acts as the entry point for working with a customer’s billing information, subscription data, invoices and more.

The API allows you to create, delete, and update your customers. You can retrieve individual customers as well as a list of all your customers and also manage notes and payment methods.

The Customer object

[Swagger:definition:json:Customer]

[Swagger:definition:table:Customer]

Get list of customers

[Swagger:request:curl:getCustomers]

The above command returns JSON structured like this

[Swagger:response:json:getCustomers]

Returns a list of customers. The customers are returned sorted by creation date by default, with the most recently created customers appearing first. Searching and sorting can be controlled with the search and sort parameters respectively.

Searching and sorting can be done using most parameters in the customer object.

For general text search the search key text can be used. The search will be done for all string parameters in the customer object.

HTTP Request

GET https://api.reepay.com/v1/customer?page={page}&size={size}&search={search}&sort={sort}

Query Parameters

[Swagger:request:table:getCustomers]

Return

Returns a Pagination object containing Customers in the content array.

Create customer

[Swagger:request:curl:createCustomerJson]

The above command returns JSON structured like this

[Swagger:response:json:createCustomerJson]

HTTP Request

POST https://api.reepay.com/v1/customer

[Swagger:request:table:createCustomerJson]

Return

Returns a Customer object.

Get customer

[Swagger:request:curl:getCustomer]

The above command returns JSON structured like this

[Swagger:response:json:getCustomer]

Retrieves the details of an existing customer. You need only supply the unique customer handle you defined upon creation.

HTTP Request

GET https://api.reepay.com/v1/customer/{handle}

[Swagger:request:table:getCustomer]

Return

Returns a Customer object.

Update customer

[Swagger:request:curl:updateCustomerJson]

The above command returns JSON structured like this

[Swagger:response:json:updateCustomerJson]

Updates the specified customer by setting the values of the parameters passed. Any parameters not provided will be deleted.

HTTP Request

PUT https://api.reepay.com/v1/customer/{handle}

[Swagger:request:table:updateCustomerJson]

Return

Returns a Customer object.

Delete customer

[Swagger:request:curl:deleteCustomer]

The above command returns JSON structured like this

[Swagger:response:json:deleteCustomer]

A customer can be soft-deleted meaning that the customer resource remains with a status deleted, and all sensitive data is removed from the resource. The customer handle is changed with a prefix deleted_xxxx_ where xxxx is a random string. This means that the original handle can be used again for a new customer. All related resources like subscriptions and invoices are not deleted.

A customer can only be deleted if has none or only expired subscriptions, and no pending or dunning invoices.

HTTP Request

DELETE https://api.reepay.com/v1/customer/{handle}

[Swagger:request:table:deleteCustomer]

Return

Returns a Customer object.

Get customer notes

[Swagger:request:curl:getCustomerNotes]

The above command returns JSON structured like this

[Swagger:response:json:getCustomerNotes]

Your team can leave notes on an customer to add context, e.g. the reason for a refund, customer requests, and/or complaints. These notes are internal and not exposed to your customers.

Use this to get a list of notes for a specific customer.

HTTP Request

GET https://api.reepay.com/v1/customer/{handle}/note

[Swagger:request:table:getCustomerNotes]

Return

Returns an array of Customer Note objects.

Create customer note

[Swagger:request:curl:createCustomerNoteJson]

The above command returns JSON structured like this

[Swagger:response:json:createCustomerNoteJson]

Create a note for a customer. Specify who has created the note by dictate user_name and user_email. The user information is not a part of Reepay’s user concept but can be your intern user information.

HTTP Request

POST https://api.reepay.com/v1/customer/{handle}/note

[Swagger:request:table:createCustomerNoteJson]

Return

Returns a Customer Note object.

Get customer payment methods

[Swagger:request:curl:getCustomerPaymentMethods]

The above command returns JSON structured like this

[Swagger:response:json:getCustomerPaymentMethods]

Get payment methods for subscription. Currently a list of card objects. It can be chosen to only get active payment methods, that is methods that are not in-activated or failed.

HTTP Request

GET https://api.reepay.com/v1/customer/{handle}/payment_method

[Swagger:request:table:getCustomerPaymentMethods]

Return

[Swagger:response:table:getCustomerPaymentMethods]

The Card object.

Add card payment method

[Swagger:request:curl:addCardJson]

The above command returns JSON structured like this

[Swagger:response:json:addCardJson]

Add a new card payment method to the customer. The card can subsequently be assigned to existing subscriptions and used for new susbcriptions.

HTTP Request

POST https://api.reepay.com/v1/customer/{handle}/payment_method/card

[Swagger:request:table:addCardJson]

Return

Return a Card object.

Get card

[Swagger:request:curl:getCard]

The above command returns JSON structured like this

[Swagger:response:json:getCard]

Get card payment method information

HTTP Request

GET https://api.reepay.com/v1/customer/{handle}/payment_method/card/{id}

[Swagger:request:table:getCard]

Return

Return a Card object.

Get card details

[Swagger:request:curl:getCardDetails]

The above command returns JSON structured like this

[Swagger:response:json:getCardDetails]

Get payment gateway specific information for card.

HTTP Request

GET https://api.reepay.com/v1/customer/{handle}/payment_method/card/{id}/details

[Swagger:request:table:getCardDetails]

Return

Returns a JSON object with acquirer specific key/value details for the card.

Import card payment method

[Swagger:request:curl:importCardJson]

The above command returns JSON structured like this

[Swagger:response:json:importCardJson]

Import a card using an existing card identifier from a card payment gateway for which the account has an agreement. The card can subsequently be assigned to existing subscriptions and used for new susbcriptions.

HTTP Request

POST https://api.reepay.com/v1/customer/{handle}/payment_method/card_import

[Swagger:request:table:importCardJson]

Return

Return a Card object.

Inactivate payment method

[Swagger:request:curl:inactivatePaymentMethod]

The above command returns JSON structured like this

[Swagger:response:json:inactivatePaymentMethod]

A payment method can be inactivated. An inactivated payment method will not be used to pay invoices.

HTTP Request

POST https://api.reepay.com/v1/customer/{handle}/payment_method/{method_id}/inactivate

[Swagger:request:table:inactivatePaymentMethod]

Return

[Swagger:response:table:inactivatePaymentMethod]

The Card object.

Activate payment method

[Swagger:request:curl:activatePaymentMethod]

The above command returns JSON structured like this

[Swagger:response:json:activatePaymentMethod]

A previously inactivated payment method can be re-activated.

HTTP Request

POST https://api.reepay.com/v1/customer/{handle}/payment_method/{method_id}/activate

[Swagger:request:table:activatePaymentMethod]

Return

[Swagger:response:table:activatePaymentMethod]

The Card object.

Reactivate failed card

[Swagger:request:curl:reactivateCard]

The above command returns JSON structured like this

[Swagger:response:json:reactivateCard]

A failed card can be reactivated in the case of wrong marking as failed. The card will be available to use as payment method on on-demand invoices and subscriptions. If already used on subscription with pending or dunning invoices the card will be retried as payment method.

HTTP Request

POST https://api.reepay.com/v1/customer/{handle}/payment_method/{card_id}/card_reactivate

[Swagger:request:table:reactivateCard]

Return

The Card object.

Create invoice for customer

[Swagger:request:curl:createCustomerInvoice]

The above command returns JSON structured like this

[Swagger:response:json:createCustomerInvoice]

A one-time invoice can be created on demand for a customer by providing a number of order lines. The invoice can later be settled using a customer payment method or using a manual transfer e.g. bank transfer. The creation and settlement can also be done in one operation by either supplying a settle payment method or a manual transfer to the create operation. The result of the creation is an invoice with state pending if not settled directly, or state settled or failed depending on the result of the immediate settle attempt.

HTTP Request

POST https://api.reepay.com/v1/customer/{handle}/invoice

[Swagger:request:table:createCustomerInvoice]

Returns

Returns an Invoice object for the created invoice.

Subscription

Subscriptions tie customers to plans and are responsible for billing according to the billing schedule defined on the plan. A customer can have multiple subscriptions. A customer subscribing to a plan is the result of a subscription sign up

For a simple example of how to use the subscription resource see our Wiki on Github.

The Subscription object

[Swagger:definition:json:Subscription]

[Swagger:definition:table:Subscription]

Get list of subscriptions

[Swagger:request:curl:getSubscriptions]

The above command returns JSON structured like this

[Swagger:response:json:getSubscriptions]

Returns a list of subscriptions. The subscriptions are returned sorted by creation date by default, with the most recently created subscriptions appearing first. Searching and sorting can be controlled with the search and sort parameters respectively.

Searching and sorting can be done using most parameters in the subscription object. Searching on related resources customer and plan can be achieved with the search parameters customer.handle and plan.handle. Sorting on plan handle and created date, and customer handle and creation date, is possible with the sort parameters: plan.handle, plan.created, customer.handle and customer.created.

For general text search the search key text can be used. The search will be done for all string parameters in the related customer and plan objects.

Subscriptions can also be searched based on attached subscription add-ons and the add-ons for the susbcription add-ons. To search for subscriptions with attached subscription add-on subscription_add_on.handle can be used where the argument is the subscription add-on handle. E.g. to search for all active subscriptions with attached subscription add-on with handle xa431133 the following search query can be used:

GET https://api.reepay.com/v1/subscription?search=subscription_add_on.handle:xa431133,state:active

To search for all active subscriptions where the subscription add-ons are based on add-on with handle the search query add_on.handle can be used. E.g. to search for all subscriptions with subscription add-ons based on add-on with handle extra_users the following query can be used:

GET https://api.reepay.com/v1/subscription?search=add_on.handle:extra_users,state:active

HTTP Request

GET https://api.reepay.com/v1/subscription?page={page}&size={size}&search={search}&sort={sort}

Query Parameters

[Swagger:request:table:getSubscriptions]

Returns

Returns a Pagination object containing Subscriptions in the content array.

Create subscription

[Swagger:request:curl:createSubscriptionJson]

The above command returns JSON structured like this

[Swagger:response:json:createSubscriptionJson]

Create a subscription (and optionally customer). Payment information can be obtained in one of the following ways:

The parameter start_date is optional and indicates when the subscription is eligible to begin the first billing period. Whether the first billing period i starting at start_date depends on the schedule type on the plan for the subscription. If a fixed day schedule type is used, the first billing period will start on the first fixed day after start_date.

A subscription creation can be made conditional on a successful payment of the first invoice. See the parameter conditional_create. This will require a signup method of source, and the subscription must be eligible for billing for the first period right away.

When creating a subscription either a reference to an existing customer must be provided, or a customer can be created in the same operation using the parameter create_customer. The operation is atomic, so if subscription create fails, no customer will be created.

An example of how to use the create subscription API operation can be fore here.

To add subscription add-ons when creating a list of CreateSubscriptionAddOn objects can be provided in parameter add_ons. An example on the use of add-ons can be found here.

HTTP Request

POST https://api.reepay.com/v1/subscription

[Swagger:request:table:createSubscriptionJson]

Returns

Returns the created Subscription object.

Get subscription

[Swagger:request:curl:getSubscription]

The above command returns JSON structured like this

[Swagger:response:json:getSubscription]

HTTP Request

GET https://api.reepay.com/v1/subscription/{handle}

[Swagger:request:table:getSubscription]

Returns

Returns the requested Subscription object.

Cancel subscription

[Swagger:request:curl:cancelSubscription]

The above command returns JSON structured like this

[Swagger:response:json:cancelSubscription]

An active subscription can be cancelled. When the subscription will expire is determined by possible notice and fixation period defined for the plan, or optional overriding notice period defined in the cancel request. By default the subscription will expire at the end of the current billing period. Cancelling a subscription in trial will always result in an expire at the end of the trial period.

HTTP Request

POST https://api.reepay.com/v1/subscription/{handle}/cancel

[Swagger:request:table:cancelSubscription]

Returns

Returns the cancelled Subscription object with is_cancelled=true and the parameter expires set to when the subscription will expire.

Change subscription

Plan, add-ons, amount and plan quantity can be changed either immediately or at next renewal. Typically upgrades will be done immediate and downgrades at next renewal.

To change subscription add-ons a list of subscription add-on handles to remove can be provided and a list of CreateSubscriptionAddOn objects can be provided to attach new subscription add-ons. A subscription add-on cannot be updated, but instead a remove and an attach of the same add-on can be performed. To only change add-ons immediately without any compensation or new billing, a change with add-on paramteres and compensation_method=none and billing=none can be performed. An example on the use of add-ons can be found here.

[Swagger:request:curl:changeSubscription]

HTTP Request

PUT https://api.reepay.com/v1/subscription/{handle}

[Swagger:request:table:changeSubscription]

Returns

Returns a Subscription object.

Change next renewal date

[Swagger:request:curl:changeNextPeriodStartJson]

The above command returns JSON structured like this

[Swagger:response:json:changeNextPeriodStartJson]

The start of the next billing period can be adjusted. The new date is required to be in the future. Notice that the effect of using this functionality is different if a fixed day schedule type is used. If such is used the actual next billing period start will be the first fixed day after the given date.

HTTP Request

POST https://api.reepay.com/v1/subscription/{handle}/change_next_period_start

[Swagger:request:table:changeNextPeriodStartJson]

Returns

Returns the Subscription object, which just had its renewal date changed.

Subscription on hold

[Swagger:request:curl:onHold]

The above command returns JSON structured like this

[Swagger:response:json:onHold]

Put subscription instantly on hold. The operation will fail if the subscription has pending or dunning invoices. Handle these separately, e.g. by cancelling all dunning and pending. A subscription on hold can later be reactivated. An optional argument can be given describing how to compensate for the current period if already paid for with settled invoice.

HTTP Request

POST https://api.reepay.com/v1/subscription/{handle}/on_hold

[Swagger:request:table:onHold]

Returns

Returns the Subscription object, with state on_hold.

Reactivate subscription

[Swagger:request:curl:reactivateSubscription]

The above command returns JSON structured like this

[Swagger:response:json:reactivateSubscription]

A subscription on hold can be reactivated to active state. An optional start date can be given to control from when the subscription is eligible to start first billing period after on hold. The plan handling of potential partial periods can be overridden using an optional argument.

HTTP Request

POST https://api.reepay.com/v1/subscription/{handle}/reactivate

[Swagger:request:table:reactivateSubscription]

Returns

Returns the Subscription object, with state active.

Expire subscription

[Swagger:request:curl:expire]

The above command returns JSON structured like this

[Swagger:response:json:expire]

Expire the subscription instantly. The operation will fail if the subscription has pending or dunning invoices. Handle these separately, e.g. by cancelling all dunning and pending. Expire can be given an optional argument describing how to compensate for the current period if already paid for with settled invoice.

HTTP Request

POST https://api.reepay.com/v1/subscription/{handle}/expire

[Swagger:request:table:expire]

Returns

Returns the Subscription object, with state expired.

Get payment methods

[Swagger:request:curl:getSubscriptionPaymentMethods]

The above command returns JSON structured like this

[Swagger:response:json:getSubscriptionPaymentMethods]

Get payment methods for subscription. Currently a list of card objects.

HTTP Request

GET https://api.reepay.com/v1/subscription/{handle}/payment_method

[Swagger:request:table:getSubscriptionPaymentMethods]

Returns

[Swagger:response:table:getSubscriptionPaymentMethods]

The Card object.

Remove all payment methods

[Swagger:request:curl:removeAllPaymentMethods]

The above command returns JSON structured like this

[Swagger:response:json:removeAllPaymentMethods]

Remove all payment methods from subscription.

HTTP Request

DELETE https://api.reepay.com/v1/subscription/{handle}/payment_method

[Swagger:request:table:removeAllPaymentMethods]

Returns

[Swagger:response:table:removeAllPaymentMethods]

The Card object.

Set payment method

[Swagger:request:curl:setPaymentMethod]

The above command returns JSON structured like this

[Swagger:response:json:setPaymentMethod]

Set payment method for the subscription, either by an existing customer payment method reference, or a card token obtained using the Reepay JS library.

HTTP Request

POST https://api.reepay.com/v1/subscription/{handle}/payment_method

[Swagger:request:table:setPaymentMethod]

Returns

[Swagger:response:table:setPaymentMethod]

The Card object.

Remove payment method

[Swagger:request:curl:removePaymentMethod]

The above command returns JSON structured like this

[Swagger:response:json:removePaymentMethod]

Remove a specific payment method from subscription.

HTTP Request

DELETE https://api.reepay.com/v1/subscription/{handle}/payment_method/{method_id}

[Swagger:request:table:removePaymentMethod]

Returns

[Swagger:response:table:removePaymentMethod]

The Card object.

Uncancel subscription

[Swagger:request:curl:uncancel]

The above command returns JSON structured like this

[Swagger:response:json:uncancel]

A cancelled subscription can be made active again, not expiring it at the end of current billing period.

HTTP Request

POST https://api.reepay.com/v1/subscription/{handle}/uncancel

[Swagger:request:table:uncancel]

Returns

Returns the Subscription object, which has been uncancelled.

Create invoice for subscription

[Swagger:request:curl:createSubscriptionInvoice]

The above command returns JSON structured like this

[Swagger:response:json:createSubscriptionInvoice]

A one-time invoice can be created on demand for a subscription. It is configurable in the request where the order lines for the invoice should come from. The following are possible:

By default the invoice is generated and tried settled using the payment method attached to the subscription. If it cannot be settled it will enter dunning management as automatically generated subscription invoices. It is also possible to let the outcome of a creation be either a settled or a failed invoice by using the instant parameter. This can be used for subscription invoices not relevant for possible dunning management.

Optionally either an offline manual transfer or a settle with an alternative payment method can be given for the invoice creation. The manual transfer will always settle the invoice. If a settle using an alternative payment method fails, the invoice will left pending if instant is not used, and failed otherwise.

HTTP Request

POST https://api.reepay.com/v1/subscription/{handle}/invoice

[Swagger:request:table:createSubscriptionInvoice]

Returns

Returns an Invoice object for the created invoice.

Get subscription add-ons

[Swagger:request:curl:getSubscriptionAddOns]

The above command returns JSON structured like this

[Swagger:response:json:getSubscriptionAddOns]

Get subscription add-ons attached to subscription.

HTTP Request

GET https://api.reepay.com/v1/subscription/{handle}/add_on

[Swagger:request:table:getSubscriptionAddOns]

Return

Returns an array of Subscription Add-On objects.

Get subscription add-on

[Swagger:request:curl:getSubscriptionAddOn]

The above command returns JSON structured like this

[Swagger:response:json:getSubscriptionAddOn]

Get subscription add-on attached to subscription.

HTTP Request

GET https://api.reepay.com/v1/subscription/{handle}/add_on/{saHandle}

[Swagger:request:table:getSubscriptionAddOn]

Return

Returns a Subscription Add-On object.

Get subscription discounts

[Swagger:request:curl:getSubscriptionDiscounts]

The above command returns JSON structured like this

[Swagger:response:json:getSubscriptionDiscounts]

Get subscription discounts attached to subscription. Active, and deleted that has been applied to one or more invoices, will be returned.

HTTP Request

GET https://api.reepay.com/v1/subscription/{handle}/discount

[Swagger:request:table:getSubscriptionDiscounts]

Return

Returns an array of SubscriptionDiscount objects.

Get subscription discount

[Swagger:request:curl:getSubscriptionDiscount]

The above command returns JSON structured like this

[Swagger:response:json:getSubscriptionDiscount]

Get subscription discount attached to subscription.

HTTP Request

GET https://api.reepay.com/v1/subscription/{handle}/discount/{sdHandle}

[Swagger:request:table:getSubscriptionDiscount]

Return

Returns a SubscriptionDiscount object.

Add subscription discount

[Swagger:request:curl:createSubscriptionDiscount]

The above command returns JSON structured like this

[Swagger:response:json:createSubscriptionDiscount]

Add a subscription discount using discount as template. Only discount argument is mandatory the rest of the arguments can be used to override the settings on the discount.

HTTP Request

POST https://api.reepay.com/v1/subscription/{handle}/discount

[Swagger:request:table:createSubscriptionDiscount]

Return

Returns a SubscriptionDiscount object.

Delete subscription discount

[Swagger:request:curl:deleteSubscriptionDiscount]

The above command returns JSON structured like this

[Swagger:response:json:deleteSubscriptionDiscount]

Remove a subscription discount from a subscription.

HTTP Request

DELETE https://api.reepay.com/v1/subscription/{handle}/discount/{sdHandle}

[Swagger:request:table:deleteSubscriptionDiscount]

Return

Returns a SubscriptionDiscount object.

Redeem coupon code

Redeem a coupon code for subscription.

[Swagger:request:curl:redeemCouponCode]

The above command returns JSON structured like this

[Swagger:response:json:redeemCouponCode]

HTTP Request

POST https://api.reepay.com/v1/subscription/{handle}/coupon

[Swagger:request:table:redeemCouponCode]

Return

Returns a CouponRedemption object consisting of redeemed Coupon and the released SubscriptionDiscount.

Period balance

[Swagger:request:curl:getSubscriptionPeriodBalance]

The above command returns JSON structured like this

[Swagger:response:json:getSubscriptionPeriodBalance]

Calculate the balance of the subscription for the period containing the given date (defaults to now). The period balance describes how much have been paid (and the invoice paid with), how much of the paid amount that has been consumed and how much is remaining. Consumed and remaining amount is calculated from the fraction of the period that has already elapsed.

HTTP Request

GET https://api.reepay.com/v1/subscription/{handle}/period_balance

Query Parameters

[Swagger:request:table:getSubscriptionPeriodBalance]

Returns

Returns a SubscriptionPeriodBalance object.

Add-on

Add-ons are templates for optional additional products that can be attached to a subscription. Add-ons attached to a subscription are called subscription add-ons. A subscription add-on will result in an additional charge billed each billing period in addition to a subscription’s base charge. An example on the use of add-ons can be found here.

The Add-On object

[Swagger:definition:json:AddOn]

[Swagger:definition:table:AddOn]

Get list of add-ons

[Swagger:request:curl:getAddOns]

The above command returns JSON structured like this

[Swagger:response:json:getAddOns]

Returns a list of add-ons. The add-ons are returned sorted by creation date by default, with the most recently created add-ons appearing first. Searching and sorting can be controlled with the search and sort parameters respectively.

Searching and sorting can be done using most parameters on the add-on object.

HTTP Request

GET https://api.reepay.com/v1/add_on?page={page}&size={size}&search={search}&sort={sort}

Query Parameters

[Swagger:request:table:getAddOns]

Return

Returns a Pagination object containing AddOns in the content array.

Get add-on

[Swagger:request:curl:getAddOn]

The above command returns JSON structured like this

[Swagger:response:json:getAddOn]

Get add-on by handle.

HTTP Request

GET https://api.reepay.com/v1/add_on/{handle}

[Swagger:request:table:getAddOn]

Return

Returns an Add-on object.

Create add-on

[Swagger:request:curl:createAddOn]

The above command returns JSON structured like this

[Swagger:response:json:createAddOn]

An add-on is given a handle for own reference. Name will be reflected on the invoice.

HTTP Request

POST https://api.reepay.com/v1/add_on

[Swagger:request:table:createAddOn]

Return

Returns an Add-on object.

Update add-on

[Swagger:request:curl:updateAddOn]

The above command returns JSON structured like this

[Swagger:response:json:updateAddOn]

Update add-on

HTTP Request

PUT https://api.reepay.com/v1/add_on/{handle}

[Swagger:request:table:updateAddOn]

Return

Returns an Add-on object.

Delete add-on

[Swagger:request:curl:deleteAddOn]

The above command returns JSON structured like this

[Swagger:response:json:deleteAddOn]

Delete add-on.

HTTP Request

DELETE https://api.reepay.com/v1/add_on/{handle}

[Swagger:request:table:deleteAddOn]

Return

Returns the deleted Add-on object.

Additional cost

Additional costs can be added to subscriptions. Additional costs for a subscription will be collected at next renewal and added to the invoice.

The Additional cost object

[Swagger:definition:json:AdditionalCost]

[Swagger:definition:table:AdditionalCost]

Create additional cost

[Swagger:request:curl:createAdditionalCostJson]

The above command returns JSON structured like this

[Swagger:response:json:createAdditionalCostJson]

An additional cost is given a handle for own reference. Order text will be reflected on the invoice. Notice that the amount is per quantity meaning that the total amount transferred to the invoice is quantity times amount.

HTTP Request

POST https://api.reepay.com/v1/additional_cost

[Swagger:request:table:createAdditionalCostJson]

Returns

Returns the new Additional cost object.

Get additional costs for subscription

[Swagger:request:curl:getAdditionalCosts]

The above command returns JSON structured like this

[Swagger:response:json:getAdditionalCosts]

Get all additional costs for subscription.

HTTP Request

GET https://api.reepay.com/v1/additional_cost/subscription/{handle}

[Swagger:request:table:getAdditionalCosts]

Returns

Returns an array of Additional costs objects.

Get additional cost

[Swagger:request:curl:getAdditionalCost]

The above command returns JSON structured like this

[Swagger:response:json:getAdditionalCost]

Get single additional cost by handle

HTTP Request

GET https://api.reepay.com/v1/additional_cost/{handle}

[Swagger:request:table:getAdditionalCost]

Returns

Returns an Additional costs objects.

Cancel pending additional cost

[Swagger:request:curl:cancelAdditionalCost]

The above command returns JSON structured like this

[Swagger:response:json:cancelAdditionalCost]

Cancel a pending additional cost

HTTP Request

POST https://api.reepay.com/v1/additional_cost/{handle}/cancel

[Swagger:request:table:cancelAdditionalCost]

Returns

Returns the cancelled pending Additional costs objects.

Credit

Credits can be added to subscriptions. Credits will be collected and deducted from invoice amount at next automatic renewal or optionally when a one-time invoice is created. If the credit amount is higher than the invoice amount, the remaining amount will be deducted from future invoices. Any additional costs will be added to the invoice amount before credit deduction.

The Credit object

[Swagger:definition:json:Credit]

[Swagger:definition:table:Credit]

Create credit

[Swagger:request:curl:createCreditJson]

The above command returns JSON structured like this

[Swagger:response:json:createCreditJson]

A credit is given a handle for own reference. Text will be reflected on the invoice.

HTTP Request

POST https://api.reepay.com/v1/credit

[Swagger:request:table:createCreditJson]

Return

Returns a Credit object.

Get credits for subscription

[Swagger:request:curl:getCredits]

The above command returns JSON structured like this

[Swagger:response:json:getCredits]

Get all credits for subscription.

HTTP Request

GET https://api.reepay.com/v1/credit/subscription/{handle}

[Swagger:request:table:getCredits]

Return

Returns an array of Credit objects.

Get credit

[Swagger:request:curl:getCredit]

The above command returns JSON structured like this

[Swagger:response:json:getCredit]

Get credit by handle

HTTP Request

GET https://api.reepay.com/v1/credit/{handle}

[Swagger:request:table:getCredit]

Return

Returns a Credit object.

Cancel credit

[Swagger:request:curl:cancelCredit]

The above command returns JSON structured like this

[Swagger:response:json:cancelCredit]

Cancel a pending credit

HTTP Request

POST https://api.reepay.com/v1/credit/{handle}/cancel

[Swagger:request:table:cancelCredit]

Return

Returns a Credit object.

Discount

Discounts are used as templates for discounts applied to subscriptions. A discount defines how much to discount, either fixed amount or percentage, what order lines to discount, and for how long to discount.

The Discount object

[Swagger:definition:json:Discount]

[Swagger:definition:table:Discount]

Get list of discounts

[Swagger:request:curl:getDiscounts]

The above command returns JSON structured like this

[Swagger:response:json:getDiscounts]

Returns a list of discounts. The discounts are returned sorted by creation date by default, with the most recently created discounts appearing first. Searching and sorting can be controlled with the search and sort parameters respectively.

Searching and sorting can be done using most parameters on the discount object.

HTTP Request

GET https://api.reepay.com/v1/discount?page={page}&size={size}&search={search}&sort={sort}

Query Parameters

[Swagger:request:table:getDiscounts]

Return

Returns a Pagination object containing Discounts in the content array.

Get discount

[Swagger:request:curl:getDiscount]

The above command returns JSON structured like this

[Swagger:response:json:getDiscount]

Get discount by handle.

HTTP Request

GET https://api.reepay.com/v1/discount/{handle}

[Swagger:request:table:getDiscount]

Return

Returns an Discount object.

Create discount

[Swagger:request:curl:createDiscount]

The above command returns JSON structured like this

[Swagger:response:json:createDiscount]

A discount is given a handle for own reference. Name will be reflected on the invoice.

HTTP Request

POST https://api.reepay.com/v1/discount

[Swagger:request:table:createDiscount]

Return

Returns an Discount object.

Delete discount

[Swagger:request:curl:deleteDiscount]

The above command returns JSON structured like this

[Swagger:response:json:deleteDiscount]

Delete discount.

HTTP Request

DELETE https://api.reepay.com/v1/discount/{handle}

[Swagger:request:table:deleteDiscount]

Return

Returns the deleted Discount object.

Coupon

Coupons can be used to generate codes for discounts that can be redeemed for subscriptions, either at subscription creation or subsequently. Coupons are a great tool for a promotion, special offer, or sale strategy.

The Coupon object

[Swagger:definition:json:Coupon]

[Swagger:definition:table:Coupon]

Get list of coupons

[Swagger:request:curl:getCoupons]

The above command returns JSON structured like this

[Swagger:response:json:getCoupons]

Returns a list of coupons. The coupons are returned sorted by creation date by default, with the most recently created coupons appearing first. Searching and sorting can be controlled with the search and sort parameters respectively. To filter on the state of coupon use search=state:active and search=state:expired to get active and expired coupons respectively.

Searching and sorting can be done using most parameters on the coupons object.

HTTP Request

GET https://api.reepay.com/v1/coupon?page={page}&size={size}&search={search}&sort={sort}

Query Parameters

[Swagger:request:table:getCoupons]

Return

Returns a Pagination object containing Coupons in the content array.

Get coupon

[Swagger:request:curl:getCoupon]

The above command returns JSON structured like this

[Swagger:response:json:getCoupon]

Get coupon by handle.

HTTP Request

GET https://api.reepay.com/v1/coupon/{handle}

[Swagger:request:table:getCoupon]

Return

Returns a Coupon object.

Create coupon

Create a coupon. The coupon code needs to be unique for the currently active coupons.

[Swagger:request:curl:createCoupon]

The above command returns JSON structured like this

[Swagger:response:json:createCoupon]

HTTP Request

POST https://api.reepay.com/v1/coupon

[Swagger:request:table:createCoupon]

Return

Returns a Coupon object.

Update coupon

Some attributes can be updated on an active coupon.

[Swagger:request:curl:updateCoupon]

The above command returns JSON structured like this

[Swagger:response:json:updateCoupon]

HTTP Request

PUT https://api.reepay.com/v1/coupon/{handle}

[Swagger:request:table:updateCoupon]

Return

Returns a Coupon object.

Expire coupon

An actie coupon can be expired early.

[Swagger:request:curl:expireCoupon]

The above command returns JSON structured like this

[Swagger:response:json:expireCoupon]

HTTP Request

POST https://api.reepay.com/v1/coupon/{handle}/expire

[Swagger:request:table:expireCoupon]

Return

Returns a Coupon object.

Delete coupon

An coupon with no redemptions can be deleted.

[Swagger:request:curl:deleteCoupon]

The above command returns JSON structured like this

[Swagger:response:json:deleteCoupon]

HTTP Request

DELETE https://api.reepay.com/v1/coupon/{handle}

[Swagger:request:table:deleteCoupon]

Return

Returns the deleted Coupon object.

Validate coupon code

Before doing an actual redemption the validity and eligibility of a coupon code can be tested. Customer and plan arguments are optional but if not given the actual eligibility for customer and plan are not tested.

[Swagger:request:curl:validateCode]

The above command returns JSON structured like this

[Swagger:response:json:validateCode]

HTTP Request

GET https://api.reepay.com/v1/coupon/code/validate

[Swagger:request:table:validateCode]

Return

Returns eligible Coupon object or HTTP 404 if none can be found.

Invoice

Subscription billing, additional costs and credits are collected in invoices. An invoice is settled through card transactions or other types of transactions. Invoices are created automatically for new billing periods, but can also be created on demand for subscriptions and customers. See create invoice for subscription and create invoice for customer.

Subscription invoices are settled automatically and subject to an automated dunning process defined by the subscription plan. One-time on-demand invoices must be settled using a payment method from the customer wallet or with a manual transfer, e.g. bank transfer.

Invoices can also be settled or authorized using the Charge resource either by providing existing payment method or a one-time credit card token obtained with the Reepay Javascript Library.

A settled invoice can be refunded using the Refund resource.

The Invoice object

[Swagger:definition:json:Invoice]

[Swagger:definition:table:Invoice]

Get list of invoices

[Swagger:request:curl:getInvoices]

The above command returns JSON structured like this

[Swagger:response:json:getInvoices]

Returns a list of invoices. The invoices are returned sorted by creation date by default, with the most recently created invoices appearing first. Searching and sorting can be controlled with the search and sort parameters respectively.

Searching and sorting can be done using most parameters in the invoice object, e.g. id, handle and number. Searching on related resources customer, subscription and plan, can be achieved with the search parameters customer.handle, subscription.handle and plan.handle. Sorting on customer, plan and subscription attributes can be done using the following sort parameters: plan.handle, plan.created, customer.handle, customer.created. subscription.handle and subscription.created.

For general text search the search key text can be used. The search will be done on id, handle and number on the invoice object, and on all string parameters in the related customer, subscription and plan objects.

HTTP Request

GET https://api.reepay.com/v1/invoice?page={page}&size={size}&search={search}&sort={sort}

Query Parameters

[Swagger:request:table:getInvoices]

Return

Returns a Pagination object containing Invoices in the content array.

Get invoice

[Swagger:request:curl:getInvoice]

The above command returns JSON structured like this

[Swagger:response:json:getInvoice]

Get invoice by id or handle

HTTP Request

GET https://api.reepay.com/v1/invoice/{id}

[Swagger:request:table:getInvoice]

Return

Returns an Invoice object.

Settle invoice

[Swagger:request:curl:settle]

The above command returns JSON structured like this

[Swagger:response:json:settle]

Settle pending, dunning or failed invoice using a customer payment method or subscription payment method for a subscription invoice. For a customer invoice an optional due date and time can be supplied delaying the settle until this date and time.

HTTP Request

POST https://api.reepay.com/v1/invoice/{id}/settle

[Swagger:request:table:settle]

Return

Returns an Invoice object. The invoice state depends on the origin of the invoice. A one-time customer invoice will be either settled or failed while a subscription invoice will keep its state if the settle fails.

Cancel settle later

[Swagger:request:curl:cancelSettleLater]

The above command returns JSON structured like this

[Swagger:response:json:cancelSettleLater]

Scheduled settle later can be cancelled for at pending customer invoice

HTTP Request

POST https://api.reepay.com/v1/invoice/{id}/settle/cancel

[Swagger:request:table:cancelSettleLater]

Return

Returns an Invoice object.

Offline manual settle

[Swagger:request:curl:manualSettle]

The above command returns JSON structured like this

[Swagger:response:json:manualSettle]

A non-settled invoice can be settled using an offline manual transfer. An offline manual transfer could for example be a cash or bank transfer not handled automatically by Reepay. The invoice will be instantly settled and a receipt email is sent to the customer.

HTTP Request

POST https://api.reepay.com/v1/invoice/{id}/manual_settle

[Swagger:request:table:manualSettle]

Return

Returns an Invoice object.

Cancel invoice

[Swagger:request:curl:cancelInvoice]

The above command returns JSON structured like this

[Swagger:response:json:cancelInvoice]

An invoice with all transactions with no or only failed transaction can be cancelled. No further attempts to fulfill the invoice will be made. If the invoice is dunning the dunning process will be cancelled.

HTTP Request

POST https://api.reepay.com/v1/invoice/{id}/cancel

[Swagger:request:table:cancelInvoice]

Return

Returns an Invoice object.

Invoice reactivate

[Swagger:request:curl:reactivateInvoice]

The above command returns JSON structured like this

[Swagger:response:json:reactivateInvoice]

A failed or cancelled invoice can be put back to state pending for processing. The invoice will potentially enter a new dunning process if it is a subscription invoice.

HTTP Request

POST https://api.reepay.com/v1/invoice/{id}/reactivate

[Swagger:request:table:reactivateInvoice]

Return

Returns an Invoice object.

Detach from subscription

[Swagger:request:curl:detachFromSubscription]

The above command returns JSON structured like this

[Swagger:response:json:detachFromSubscription]

A subscription invoice with state pending, dunning or failed can be detached from the subscription and changed to a customer one-time invoice with pending state.

HTTP Request

POST https://api.reepay.com/v1/invoice/{id}/detach

[Swagger:request:table:detachFromSubscription]

Return

Returns an Invoice object.

Cancel all dunning and pending

[Swagger:request:curl:cancelAllDunningPending]

The above command returns JSON structured like this

[Swagger:response:json:cancelAllDunningPending]

Cancel all dunning and pending invoices for a subscription.

HTTP Request

POST https://api.reepay.com/v1/invoice/cancel_all_dunning_pending/subscription/{handle}

[Swagger:request:table:cancelAllDunningPending]

Return

Returns an array of Invoice objects.

Get transaction

[Swagger:request:curl:transaction]

The above command returns JSON structured like this

[Swagger:response:json:transaction]

HTTP Request

GET https://api.reepay.com/v1/invoice/{id}/transaction/{transaction}

[Swagger:request:table:transaction]

Return

Returns a Transaction object.

Get list of transactions

[Swagger:request:curl:transactionList]

The above command returns JSON structured like this

[Swagger:response:json:transactionList]

Returns a paginated list of transactions for invoice.

HTTP Request

GET https://api.reepay.com/v1/invoice/{id}/transaction?page={page}&size={size}&search={search}&sort={sort}

Query Parameters

[Swagger:request:table:transactionList]

Return

Returns a Pagination object containing Transactions in the content array.

Cancel transaction

[Swagger:request:curl:cancelTransaction]

The above command returns JSON structured like this

[Swagger:response:json:cancelTransaction]

Cancel a pending transaction.

HTTP Request

POST https://api.reepay.com/v1/invoice/{id}/transaction/{transaction}/cancel

[Swagger:request:table:cancelTransaction]

Return

Returns a Transaction object.

Get transaction details

[Swagger:request:curl:transactionDetails]

The above command returns JSON structured like this

[Swagger:response:json:transactionDetails]

HTTP Request

GET https://api.reepay.com/v1/invoice/{id}/transaction/{transaction}/details

[Swagger:request:table:transactionDetails]

Return

Returns a JSON object with acquirer specific key/value details for the transaction.

Charge

Charges are an abstraction on top of invoices, providing a convenient way to charge customers with one-time payments and to pay existing unpaid invoices. Charges are basically a combination of an invoice and a payment transaction . Charges allow to pay either with a direct settle or with a two-step process consisting of an authorization reserving an amount, and a subsequent settle. The handle for a charge is also the invoice handle and can be seen as an order identification in own shopping system. If an invoice does not already exist an invoice will be created and a payment transaction performed. After a payment attempt the resulting invoice will be in one of the following states: settled, authorizedor failed. If the charge is failed it can be retried with the same handle.

To create a charge a customer needs to be provided. This can either be a reference to an existing customer, or a create/update customer object. If an object is provided the customer will be created if the customer does not already exist, or the existing customer will be updated with the information provided.

The amount for a charge is given either with the argument amount and optionally ordertext, or by providing a list of detailed order lines.

To create a charge a payment source must be provided. The source can either be:

These two options allows to let the customer choose to either use an existing saved payment method, or paying with credit card information entered specifically for this charge.

The charge resource allows the use of an idempotency key to retry the same request multiple times. Multiple calls with the same key will yield the same result. This is convenient in cases of network outages where the result of a call is not received. In this case the same call can be retried. If the outcome a create charge is a failed charge a different idempotency key needs to be provided for a subsequent attempt to pay the same charge. Notice that even without using the idempotency key there is no risk of moving money twice when using the same handle. The operations around an invoice is locked, and an invoice can only be settled/authorized once.

The result of a charge can be monitored using webhooks by listening for the following events :

An authorized invoice must normally be settled within seven days before the authorization expire. An authorization can also be cancelled resulting in an attempt to void the reservation of money. A cancel will result in an invoice with state cancelled.

The Charge object

[Swagger:definition:json:Charge]

[Swagger:definition:table:Charge]

Get list of charges

[Swagger:request:curl:getCharges]

The above command returns JSON structured like this

[Swagger:response:json:getCharges]

Get paginated list of charges. Charges in this respect is invoices that have been created as charges. The charges are returned sorted by creation date by default, with the most recently created charges appearing first. Searching and sorting can be controlled with the search and sort parameters respectively.

Searching and sorting can be done using most parameters in the charge object.

HTTP Request

GET https://api.reepay.com/v1/charge?page={page}&size={size}&search={search}&sort={sort}

Query Parameters

[Swagger:request:table:getCharges]

Return

Returns a Pagination object containing Charges in the content array.

Get charge

[Swagger:request:curl:getCharge]

The above command returns JSON structured like this

[Swagger:response:json:getCharge]

Get charge by invoice id or handle

HTTP Request

GET https://api.reepay.com/v1/charge/{handle}

[Swagger:request:table:getCharge]

Return

Returns a Charge object.

Create charge

[Swagger:request:curl:createCharge]

The above command returns JSON structured like this

[Swagger:response:json:createCharge]

HTTP Request

POST https://api.reepay.com/v1/charge

[Swagger:request:table:createCharge]

Return

Returns a Charge object.

Settle charge

[Swagger:request:curl:settleCharge]

The above command returns JSON structured like this

[Swagger:response:json:settleCharge]

Settle an authorized charge. This is the second step in a two-step payment process with an authorization and subsequent settle. Optionally the amount and order lines of the charge can be adjusted.

HTTP Request

POST https://api.reepay.com/v1/charge/{handle}/settle

[Swagger:request:table:settleCharge]

Return

Returns a Charge object.

Cancel charge

[Swagger:request:curl:cancelCharge]

The above command returns JSON structured like this

[Swagger:response:json:cancelCharge]

Cancel an authorized charge. A void of reserved money will be attempted.

HTTP Request

POST https://api.reepay.com/v1/charge/{handle}/cancel

[Swagger:request:table:cancelCharge]

Return

Returns a Charge object.

Refund

The refund resource allows refunds on settled invoices/charges. Multiple refunds can be created for an invoice but only up to the settled amount can be refunded. A successful refund will result in a credit note attached to the invoice. Amount is optional and can be specified either as a single amount or as a list of credit note lines which optionally can be linked to the order lines on the invoice.

The refund resource allows the use of an idempotency key to safely retry the same request multiple times. Multiple calls with the same key will yield the same result with no risk of money being moved twice. This is convenient in cases of network outages where the result of a call is not received. In this case the same call can be retried.

The result of a refund can be monitored using webhooks by listening for the following event: invoice_refund. The webhook will contain a transaction reference which is the same as the refund id. The details of the refund can be retrieved by getting the refund using this id.

A refund is normally performed as an online refund using the settled transaction, e.g. a credit card transaction where money is transferred back to the card. A refund can optionally instead be an offline manual refund. An offline manual refund could for example be a bank transfer or chargeback handled outside Reepay and not automatically by Reepay. For an invoice settled with a manual transfer, a refund must be an offline manual refund.

The Refund object

[Swagger:definition:json:Refund]

[Swagger:definition:table:Refund]

Get refund

[Swagger:request:curl:getRefund]

The above command returns JSON structured like this

[Swagger:response:json:getRefund]

Get refund by id

HTTP Request

GET https://api.reepay.com/v1/refund/{id}

[Swagger:request:table:getRefund]

Return

Returns a Refund object.

Create refund

[Swagger:request:curl:createRefund]

The above command returns JSON structured like this

[Swagger:response:json:createRefund]

HTTP Request

POST https://api.reepay.com/v1/refund

[Swagger:request:table:createRefund]

Return

Returns a Refund object.

Event

Certain events are recorded in the Reepay system and are the triggers for sending mails and issuing webhooks. An event is tied to one or more of the main resources: customer, subscription and invoice. An event can be tied to several resources, e.g. an event tied to invoice will also be tied to customer and most often also to a subscription.

Invoice events

Event Description
invoice_created Invoice has been created
invoice_settled Invoice has been settled
invoice_authorized Invoice has been authorized
invoice_dunning Invoice has entered dunning state
invoice_dunning_notification Time for sending dunning notification acording to dunning plan
invoice_dunning_cancelled An ongoing dunning process has been cancelled either because the invoice has been settled or because the invoice has been cancelled
invoice_failed Invoice has failed after unsuccessful dunning process or because of instant ondemand settle
invoice_refund A refund has been performed on a settled invoice
invoice_reactivate A failed or cancelled invoice has been reactivated to state pending for processing
invoice_cancelled Invoice has been cancelled
invoice_changed State has not changed but other attributes on the invoice has changed. E.g. settle later cancel.

Subscription events

Event Description
subscription_created Subscription has been created
subscription_payment_method_added A payment method has been added to the subscription for the first time
subscription_payment_method_changed The payment method has been changed for a subscription with an existing payment method
subscription_trial_end The trial period for subscription has ended
subscription_renewal An invoice has been made and new billing period has started for subscription
subscription_cancelled Subscription has been cancelled to expire at end of current billing period
subscription_uncancelled A previous cancellation has been cancelled
subscription_on_hold Subscription has been put on hold by request
subscription_on_hold_dunning Subscription has been put on hold due to a failed dunning process
subscription_reactivated Subscription on hold has been reactivated to active state
subscription_expired Subscription has expired either by request, end of fixed life time or because cancelled and billing period has ended
subscription_expired_dunning Subscription has expired due to a failed dunning process
subscription_changed Subscription scheduling or pricing has been changed, e.g. by changed plan or changed next period start

Customer events

Event Description
customer_created Customer has been created
customer_changed Customer information has been changed
customer_deleted Customer has been deleted

The Event object

[Swagger:definition:json:Event]

[Swagger:definition:table:Event]

Get list of events

[Swagger:request:curl:getEvents]

The above command returns JSON structured like this

[Swagger:response:json:getEvents]

Events for account can be fetched in slices with no indication on total number of events. The list can be filtered on customer, subscription and invoice. Events will be ordered descending by creation date.

HTTP Request

GET https://api.reepay.com/v1/event?page={page}&size={size}&customer={customer}&subscription={subscription}&invoice={invoice}

Query Parameters

[Swagger:request:table:getEvents]

Return

An array of Event objects.

Get event

[Swagger:request:curl:getEvent]

The above command returns JSON structured like this

[Swagger:response:json:getEvent]

Get single event by id

HTTP Request

GET https://api.reepay.com/v1/event/{id}

[Swagger:request:table:getEvent]

Return

A Event object.

Webhook

Webhooks issued by Reepay can be queried through the API and can be re-issued by request. A webhook is tied to a certain event but several webhooks can exist for a single event if multiple URL’s are used to receive webhooks. See also Event and Webhook in the introduction.

The Webhook object

[Swagger:definition:json:Webhook]

[Swagger:definition:table:Webhook]

Get list of webhooks

[Swagger:request:curl:getWebhooks]

The above command returns JSON structured like this

[Swagger:response:json:getWebhooks]

Get list of webhooks in pages. The lists are sorted descending by created date. Use the last created date from current page as the created_before parameter to request the next page.

HTTP Request

GET https://api.reepay.com/v1/webhook?size={size}&state={state}&created_before={created_before}

Query Parameters

[Swagger:request:table:getWebhooks]

Returns

Returns an array of Webhooks.

Get webhooks

[Swagger:request:curl:getWebhook]

The above command returns JSON structured like this

[Swagger:response:json:getWebhook]

Get webhook by id or by event id. An event can spawn multiple webhooks.

HTTP Request

GET https://api.reepay.com/v1/webhook/{id}

[Swagger:request:table:getWebhook]

Returns

Returns an array of Webhooks

Get webhook requests

[Swagger:request:curl:getWebhookRequests]

The above command returns JSON structured like this

[Swagger:response:json:getWebhookRequests]

Get list of webhook requests for a webhook. The list is sorted descending by time.

HTTP Request

GET https://api.reepay.com/v1/webhook/{id}/request

[Swagger:request:table:getWebhookRequests]

Returns

Returns an array of WebhookRequests

Re-send webhooks

[Swagger:request:curl:resendJson]

The above command returns JSON structured like this

[Swagger:response:json:resendJson]

Webhooks can be re-sent. A list of webhook ids or event ids identifying the webhooks must be provided. A maximum of 100 ids is allowed for each request.

HTTP Request

POST https://api.reepay.com/v1/webhook/resend

[Swagger:request:table:resendJson]

Returns

Returns an array of Webhooks, containing all the webhooks which has been scheduled for re-send. The webhooks state will have been changed back to pending.

Disable webhooks

[Swagger:request:curl:disableWebhooks]

The above command returns JSON structured like this

[Swagger:response:json:disableWebhooks]

Pending webhooks can be disabled. A list of webhook ids or event ids identifying the webhooks must be provided. A maximum of 100 ids is allowed for each request.

HTTP Request

POST https://api.reepay.com/v1/webhook/disable

[Swagger:request:table:disableWebhooks]

Returns

Returns an array of Webhooks, containing all the webhooks which has been disabled. The webhooks state will have been changed to disabled.

Update webhooks

[Swagger:request:curl:updateWebhooks]

The above command returns JSON structured like this

[Swagger:response:json:updateWebhooks]

Webhooks can be updated and re-sent in one operation. New URL, optional HTTP username, optional HTTP password, and a list of webhook ids or event ids identifying the webhooks must be provided. A maximum of 100 ids is allowed for each request.

HTTP Request

POST https://api.reepay.com/v1/webhook/update

[Swagger:request:table:updateWebhooks]

Returns

Returns an array of Webhooks, containing all the updated webhooks. The webhooks state will have been set to pending.

Object definitions

Account

[Swagger:definition:json:Account]

[Swagger:definition:table:Account]

Invoice

[Swagger:definition:json:Invoice]

[Swagger:definition:table:Invoice]

Transaction

[Swagger:definition:json:Transaction]

[Swagger:definition:table:Transaction]

ChargeSource

[Swagger:definition:json:ChargeSource]

[Swagger:definition:table:ChargeSource]

AdditionalCost

[Swagger:definition:json:AdditionalCost]

[Swagger:definition:table:AdditionalCost]

Customer

[Swagger:definition:json:Customer]

[Swagger:definition:table:Customer]

UpdateDunningPlan

[Swagger:definition:json:UpdateDunningPlan]

[Swagger:definition:table:UpdateDunningPlan]

CreateCustomerNote

[Swagger:definition:json:CreateCustomerNote]

[Swagger:definition:table:CreateCustomerNote]

CreditInvoice

[Swagger:definition:json:CreditInvoice]

[Swagger:definition:table:CreditInvoice]

ChangeNextPeriodStart

[Swagger:definition:json:ChangeNextPeriodStart]

[Swagger:definition:table:ChangeNextPeriodStart]

IntervalAmount

[Swagger:definition:json:IntervalAmount]

[Swagger:definition:table:IntervalAmount]

CreateSubscriptionPlan

[Swagger:definition:json:CreateSubscriptionPlan]

[Swagger:definition:table:CreateSubscriptionPlan]

CreateSubscription

[Swagger:definition:json:CreateSubscription]

[Swagger:definition:table:CreateSubscription]

SubscriptionChange

[Swagger:definition:json:SubscriptionChange]

[Swagger:definition:table:SubscriptionChange]

CreateCreditNoteLine

[Swagger:definition:json:CreateCreditNoteLine]

[Swagger:definition:table:CreateCreditNoteLine]

PaymentMethods

[Swagger:definition:json:PaymentMethods]

[Swagger:definition:table:PaymentMethods]

SetCardPaymentMethod

[Swagger:definition:json:SetCardPaymentMethod]

[Swagger:definition:table:SetCardPaymentMethod]

UpdateUserPassword

[Swagger:definition:json:UpdateUserPassword]

[Swagger:definition:table:UpdateUserPassword]

CardToken

[Swagger:definition:json:CardToken]

[Swagger:definition:table:CardToken]

Subscription

[Swagger:definition:json:Subscription]

[Swagger:definition:table:Subscription]

WebhookRequest

[Swagger:definition:json:WebhookRequest]

[Swagger:definition:table:WebhookRequest]

UpdateCustomer

[Swagger:definition:json:UpdateCustomer]

[Swagger:definition:table:UpdateCustomer]

ChangePlan

[Swagger:definition:json:ChangePlan]

[Swagger:definition:table:ChangePlan]

[Swagger:definition:json:SubscriptionLinks]

[Swagger:definition:table:SubscriptionLinks]

CreateSubscriptionInvoice

[Swagger:definition:json:CreateSubscriptionInvoice]

[Swagger:definition:table:CreateSubscriptionInvoice]

CreateCustomerInvoice

[Swagger:definition:json:CreateCustomerInvoice]

[Swagger:definition:table:CreateCustomerInvoice]

Card

[Swagger:definition:json:Card]

[Swagger:definition:table:Card]

CardTransaction

[Swagger:definition:json:CardTransaction]

[Swagger:definition:table:CardTransaction]

ManualTransaction

[Swagger:definition:json:ManualTransaction]

[Swagger:definition:table:ManualTransaction]

DunningPlan

[Swagger:definition:json:DunningPlan]

[Swagger:definition:table:DunningPlan]

CreditNoteLine

[Swagger:definition:json:CreditNoteLine]

[Swagger:definition:table:CreditNoteLine]

InvoiceCreditNote

[Swagger:definition:json:InvoiceCreditNote]

[Swagger:definition:table:InvoiceCreditNote]

Key

[Swagger:definition:json:Key]

[Swagger:definition:table:Key]

Credit

[Swagger:definition:json:Credit]

[Swagger:definition:table:Credit]

WebhookSettings

[Swagger:definition:json:WebhookSettings]

[Swagger:definition:table:WebhookSettings]

CreateOrderLine

[Swagger:definition:json:CreateOrderLine]

[Swagger:definition:table:CreateOrderLine]

UpdateAccount

[Swagger:definition:json:UpdateAccount]

[Swagger:definition:table:UpdateAccount]

UpdateOrganisation

[Swagger:definition:json:UpdateOrganisation]

[Swagger:definition:table:UpdateOrganisation]

CreateAdditionalCost

[Swagger:definition:json:CreateAdditionalCost]

[Swagger:definition:table:CreateAdditionalCost]

UpdateSubscriptionPlan

[Swagger:definition:json:UpdateSubscriptionPlan]

[Swagger:definition:table:UpdateSubscriptionPlan]

OrderLine

[Swagger:definition:json:OrderLine]

[Swagger:definition:table:OrderLine]

CustomerSearch

[Swagger:definition:json:CustomerSearch]

[Swagger:definition:table:CustomerSearch]

CardImport

[Swagger:definition:json:CardImport]

[Swagger:definition:table:CardImport]

SupersedeSubscriptionPlan

[Swagger:definition:json:SupersedeSubscriptionPlan]

[Swagger:definition:table:SupersedeSubscriptionPlan]

CreateDunningPlan

[Swagger:definition:json:CreateDunningPlan]

[Swagger:definition:table:CreateDunningPlan]

InvoiceSearch

[Swagger:definition:json:InvoiceSearch]

[Swagger:definition:table:InvoiceSearch]

UpdateWebhookSettings

[Swagger:definition:json:UpdateWebhookSettings]

[Swagger:definition:table:UpdateWebhookSettings]

RefundInvoice

[Swagger:definition:json:RefundInvoice]

[Swagger:definition:table:RefundInvoice]

SubscriptionSearch

[Swagger:definition:json:SubscriptionSearch]

[Swagger:definition:table:SubscriptionSearch]

CustomerNote

[Swagger:definition:json:CustomerNote]

[Swagger:definition:table:CustomerNote]

Organisation

[Swagger:definition:json:Organisation]

[Swagger:definition:table:Organisation]

WebhookResendRequest

[Swagger:definition:json:WebhookResendRequest]

[Swagger:definition:table:WebhookResendRequest]

Plan

[Swagger:definition:json:Plan]

[Swagger:definition:table:Plan]

CreateCredit

[Swagger:definition:json:CreateCredit]

[Swagger:definition:table:CreateCredit]

EventList

[Swagger:definition:json:EventList]

[Swagger:definition:table:EventList]

Event

[Swagger:definition:json:Event]

[Swagger:definition:table:Event]

Webhook

[Swagger:definition:json:Webhook]

[Swagger:definition:table:Webhook]

CreateCustomer

[Swagger:definition:json:CreateCustomer]

[Swagger:definition:table:CreateCustomer]

Settle

[Swagger:definition:json:Settle]

[Swagger:definition:table:Settle]

ManualSettleTransfer

[Swagger:definition:json:ManualSettleTransfer]

[Swagger:definition:table:ManualSettleTransfer]

ManualRefundTransfer

[Swagger:definition:json:ManualRefundTransfer]

[Swagger:definition:table:ManualRefundTransfer]

AddOn

[Swagger:definition:json:AddOn]

[Swagger:definition:table:AddOn]

SubscriptionAddOn

[Swagger:definition:json:SubscriptionAddOn]

[Swagger:definition:table:SubscriptionAddOn]

CreateAddOn

[Swagger:definition:json:CreateAddOn]

[Swagger:definition:table:CreateAddOn]

CreateSubscriptionAddOn

[Swagger:definition:json:CreateSubscriptionAddOn]

[Swagger:definition:table:CreateSubscriptionAddOn]

Discount

[Swagger:definition:json:Discount]

[Swagger:definition:table:Discount]

CreateDiscount

[Swagger:definition:json:CreateDiscount]

[Swagger:definition:table:CreateDiscount]

SubscriptionDiscount

[Swagger:definition:json:SubscriptionDiscount]

[Swagger:definition:table:SubscriptionDiscount]

CreateSubscriptionDiscount

[Swagger:definition:json:CreateSubscriptionDiscount]

[Swagger:definition:table:CreateSubscriptionDiscount]

DiscountSettings

[Swagger:definition:json:DiscountSettings]

[Swagger:definition:table:DiscountSettings]

Coupon

[Swagger:definition:json:Coupon]

[Swagger:definition:table:Coupon]

CreateCoupon

[Swagger:definition:json:CreateCoupon]

[Swagger:definition:table:CreateCoupon]

CouponRedemption

[Swagger:definition:json:CouponRedemption]

[Swagger:definition:table:CouponRedemption]

CancelSubscription

[Swagger:definition:json:CancelSubscription]

[Swagger:definition:table:CancelSubscription]

SubscriptionPeriodBalance

[Swagger:definition:json:SubscriptionPeriodBalance]

[Swagger:definition:table:SubscriptionPeriodBalance]