Donation experiences for fundraising pages.

Fundraising embeds are self-contained donation experiences for campaign pages, editorial pages, and seasonal giving. They are separate from Checkout: you embed the experience you need, and Octany handles the donation interaction behind it.

§ 01.1 Experiences #

§ 01.2 Embed snippet #

Each fundraising experience uses the same shape: a container element and a loader script. The api, widget, and optional lang query parameters identify the configuration and language. On WordPress, the Octany plugin adds the snippet for you.

1-click Swish

<div class="octany-swish-widget"></div>
<script
  type="module"
  src="https://give.octany.com/swish-v1/loader.js?api=https://app.octany.com/widget/{account}&widget={widget-id}&lang=sv"
></script>

Donation

<div class="octany-donate"></div>
<script
  type="module"
  src="https://give.octany.com/donate-v1/loader.js?api=https://app.octany.com/widget/{account}&widget={widget-id}&lang=sv"
></script>

Greeting

<div class="octany-greeting-widget"></div>
<script
  type="module"
  src="https://give.octany.com/greeting-v1/loader.js?api=https://app.octany.com/widget/{account}&widget={widget-id}&lang=sv"
></script>

§ 01.3 Attribution and references #

Donation and 1-click Swish record where a gift came from and, if you want, your own id for the donor. Both are captured when the donation is created and then travel with it: they surface on the resulting Order, on the Subscription for a recurring gift, and on every webhook for those resources.

UTM parameters

The loader reads utm_source, utm_medium, utm_campaign, utm_content, and utm_term from the host page URL when it boots — you don't pass anything. Link to your donation page with UTM parameters and the gift is attributed to that traffic source. A recurring gift keeps its attribution on renewal orders.

Attribution is first-touch: the first values captured for a donation stick, even if the donor edits their answers before paying.

referenceId and referenceName

Add referenceId and referenceName to the loader URL to carry your own id for the donor into Octany. They mean the same thing as on a hosted checkout URL: referenceId is the id you correlate on, referenceName is a human-readable label for admin views. Both are limited to 255 characters.

<div class="octany-donate"></div>
<script
  type="module"
  src="https://give.octany.com/donate-v1/loader.js?api=https://app.octany.com/widget/{account}&widget={widget-id}&referenceId=member_42&referenceName=Anna%20Persson"
></script>

They are read from the script URL, not from the page URL, so render the snippet server-side with the values for the signed-in supporter. A visitor cannot set a reference of their own by editing the address bar.

To find the resulting subscription later, query the API with the same id: GET /subscriptions?filter[reference_id]=member_42.

§ 01.4 Donor details and terms #

If your site already knows who the donor is — a signed-in member, a supporter clicking through from your own system — hand Donation those details and the form arrives filled in. The donor can still edit every field.

<div class="octany-donate"
  data-donor-first-name="Anna"
  data-donor-last-name="Persson"
  data-donor-email="[email protected]"
  data-donor-phone="0701234567"></div>

The same values work as ?donor_* query parameters on the host page URL, for campaign links into a page you don't render per visitor: ?donor_first_name=Anna&donor_email=anna%40example.com. Where both are present the attribute wins — the value your server rendered beats the address bar.

A personnummer is never read from the URL. Query strings travel in referrers, browser history and analytics, so that one has to come from your server-rendered markup. Unknown keys are ignored, and a custom field only fills if this embed actually renders it.

Terms your site already collected

Donation has no terms checkbox — consent is implicit in the act of giving, with the consent text shown under the pay button. If your own flow collected acceptance before the donor reached the embed, say so and name the terms you collected:

<div class="octany-donate" data-terms-accepted="member-terms-2026-08"></div>

The embed then leaves its own consent text out, and the donation records what you passed as the provenance of the consent, alongside the timestamp, IP, and user agent it already captures. Use a stable identifier for the terms version you collected, not just true — it is what the record will say a year from now.

This is read from the attribute only, never from the URL: it is the provenance of a consent record, not a display preference. It also does not replace the Swish recurring consent or the autogiro medgivande — those are collected by the payment provider in the flow itself. Asserting that your terms cover the donation is your call to make.

§ 01.5 Theming #

Theming is configured per embed in Octany admin, under the widget's appearance settings — colours, radius, shadow, fonts, and button styling. The rendered result is served with the embed configuration, so a theme change takes effect without touching your page.

Fundraising embeds render in a shadow root and set their own CSS custom properties on it, so CSS variables you declare on the host page are not read. Style the area around the embed as you like; style the embed itself in Octany admin.

§ 01.6 When to use Fundraising vs Checkout #

• Use Fundraising when the public page itself is the donation experience.
• Use Checkout when your app or site needs a hosted checkout URL, cart, or JS checkout API.
• Use Classic widget only when maintaining an existing classic integration.