Payments

Why this area exists#

Payment setup is organization-wide. A giving form, event, or program may decide what to charge, but Workspace Settings decides which payment processor Altrinum uses for the tenant and what credentials back that choice.

Confirmed processor options in the settings page:

• Stripe
• Moneris
• BBMS New checkout (EAP)

What changes after configuration#

The selected processor and credentials feed the payment settings resolver used by public flows, including:

• public donations
• paid event registration
• paid program checkout
• recurring donations
• refund handling for supported processors

In practice, a payment change is never isolated. If you change the payment processor, retest every public payment flow your organization actively uses.

Choosing a processor#

Stripe#

Stripe is treated as a production-ready path in the settings UI.

Confirmed required values for a working tenant setup:

• publishable key
• secret key

Also used:

• optional Stripe account ID for matching verification
• webhook signing secret

Stripe webhook setup matters because the settings page lists required event types for:

• one-time donations
• paid event registrations
• recurring donation invoices
• refunds

Moneris#

Moneris is also treated as a production-ready path in the settings UI.

Confirmed required values:

• store ID
• API token
• checkout ID
• environment

Optional:

• hosted tokenization profile ID for legacy flows

The tenant settings test verifies the connection by requesting a tiny Moneris preload ticket rather than charging a real payment.

BBMS New checkout#

This section is labeled EAP or beta in the implementation and should be documented that way operationally.

Confirmed required values for the basic configured state:

• environment ID
• payment configuration ID

Additional fields exist for API and capture behavior, including:

• API base URL
• OAuth client ID and secret
• subscription key
• webhook shared secret
• OAuth token URL
• capture path

Use this processor only if your team has already validated the workflow with Altrinum.

Stripe setup guidance#

1. Choose Stripe in Payments.
2. Open Stripe Settings.
3. Copy the webhook endpoint shown in the page.
4. In Stripe, add that webhook endpoint.
5. Enable the required events listed in the settings UI.
6. Paste in the publishable key, secret key, and webhook signing secret.
7. Run Test Stripe Connection.

Operational note:

• If the account ID is present, the connection test also checks that the key matches that account.

Moneris setup guidance#

1. Choose Moneris in Payments.
2. Open Moneris Settings.
3. Enter the Store ID, API Token, and Checkout ID from the same Moneris environment.
4. Set the environment to Test or Live.
5. Run Test Moneris Connection.

Operational note:

• The settings page stores the last verified time and last error, so admins can see whether the last verification worked.

BBMS New checkout guidance#

1. Choose BBMS New checkout (EAP) in Payments.
2. Enter the required environment and payment configuration values.
3. Complete the remaining API fields provided by Blackbaud or your implementation team.
4. Treat the full flow as needing end-to-end validation before launch.

Operational note:

• The donation BBMS flow uses the tenant primary color and organization name as part of inline checkout branding.

What public flows depend on payments working#

Confirmed payment-dependent flows include:

• public donation checkout
• recurring donation subscription setup
• paid event registration
• paid program checkout

Stripe webhook handling also affects:

• recurring donation invoice completion
• refund reconciliation

Common mistakes#

• entering Stripe keys but forgetting webhook setup
• mixing Moneris test and live credentials
• assuming a successful connection test means every public flow is ready without running a real end-to-end checkout
• switching processors without retesting recurring donations
• treating BBMS New checkout as fully standard when the UI still labels it EAP or beta

Known limitations and caution areas#

• Stripe is considered configured only when both publishable and secret keys are present.
• Moneris one-time checkout is implemented for donations, events, and programs.
• The Moneris recurring charge path is still not fully implemented in the gateway code. If your organization depends on recurring Moneris billing, treat that as a workflow that still needs human validation before go-live.
• BBMS New checkout is explicitly labeled early access or beta in the tenant settings experience.

What to test before going live#

Test every flow your organization actually uses:

• one one-time donation
• one recurring donation
• one paid event registration
• one paid program checkout
• one refund if your team handles refunds regularly
• one branded-domain checkout if you also use a custom domain

Related topics#

• Custom Domain Setup
• Tax Receipts and Acknowledgments
• Workspace Settings Tutorial