Payment pages

You can link Áskell payment pages directly from your own website or social media. The base URL includes the page identifier, e.g. https://askell.is/public/payments/<id>/. The URL cannot be customized yet but that is planned. The link also supports several optional query parameters that let you prefill data or control how the form behaves.

Optional parameters

All of the parameters below are optional and you can combine as many as you need. When parameters prefill fields they are only read when the page loads and the values are locked (not editable by the user) to keep the forwarded information unchanged.

Parameter	Type	Description
`name`	str	Prefills the customer’s full name and disables the name field so the user cannot change the information coming from your system.
`email`	str	Prefills the email address and locks the field. Useful when the payment link is delivered by email and the address is already verified.
`phone`	str	Prefills the phone number and locks the field. Accepts both local and international formats (e.g. `+3547701234`).
`reference`	str	Prefills the national ID or any other customer reference. The field is disabled by default so the identifier stays unchanged. If no reference is provided the field remains visible and requires user input.
`hide_reference`	bool (`true` or `1`)	Hides the ID/reference field from the UI when it has already been preset with `reference`. Has no effect unless `reference` has a value.
`subscription_reference`	str	A reference in an external system for what is purchased. On legacy payment pages it goes on the new subscription and on V2 payment pages on the contract, see Subscription reference. Useful when you maintain custom identifiers in an external system.
`language`	str	Controls the payment page language. Supported values are `en` (English) and `is` (Icelandic); if omitted, `is` is used by default.

Subscription reference

Where subscription_reference ends up depends on the kind of payment page:

Legacy payment pages, which sell plan variants, put it in reference on the new subscription (Subscription). If it is left out, the subscription gets the customer’s reference.
V2 payment pages, which sell bundles or catalog products, put it in reference on the contract they create (SubscriptionContract, see Subscription Contracts V2). There is no default there: if it is left out, the contract’s reference is null. The customer’s reference is still in customer_reference.

The reference can be at most 128 characters; a longer one is rejected with HTTP 400 and an error on subscription_reference on both kinds of payment page. On V2 payment pages it must not contain a comma either. The payment is then rejected with HTTP 400 and the code invalid_subscription_reference ({"message": ..., "code": ...}) before any customer, payment method or contract is saved. This applies to card payments and bank claims alike.

Contracts created by a V2 payment page also get askell_source in metadata, so they can be traced back to the page:

{
  "askell_source": {
    "type": "payment_page",
    "payment_page_id": 12
  }
}

Usage example

The following example shows how to prefill the main fields before the user lands on the payment page:

https://askell.is/public/payments/0/?name=J%C3%B3n%20J%C3%B3nsson&email=jon%40d%C3%A6example.com&phone=+3547701234&reference=0101701234

In this scenario the customer only needs to accept the terms and select a payment method because all personal details are already provided.

Payment pages that sell legacy plans

A payment page that sells legacy plans (PlanVariant) creates a legacy subscription when payment is made. If the account’s subscription model is contracts (Subscription contracts only in the dashboard), the payment page rejects the purchase with a 400 error whose code is legacy_subscriptions_disabled, both when the card is verified and when the payment is completed, before the card is verified or charged and before a customer or subscription is created.

The subscribe button (/subscribe-button/{plan_id}/) rejects purchases the same way, before a customer is created or anything is charged. Since it is a form for the buyer, it responds with an error page (400) with a message for the buyer rather than a JSON response with code.

Before an account is moved entirely to subscription contracts, switch its payment pages to sell from a sales channel instead of legacy plans. Payment pages that sell from a sales channel keep working unchanged. See also Subscriptions.