Hub v1.93.0 / Platform Update – Week 42 '25
This release contains serval changes and improvements that have been worked on in the past months. It contains a new payment method through PayPal, as well as features for carding attack prevention, new improvements on Payment Agreements and lastly also a way to receive status changes from the TWINT app more accurately.
Highlights in this release:
Most of the new features are automatically available to all Hub users. For unbranded card paymants via PayPal please check out the provided documentation below or reach out to RaiseNow customer support to enable this paymentmethod for you. Please note that card payments processed through Paypal only work for custom Tamaros and not in self-service yet. To make the most out of the Stripe Radar feature please have a look at our knowledge base article
Processing one-off card payments via PayPal
Adding to the already existing functionality for processing recurring payments, customers can now use PayPal to process one-off card payments as well, if the merchants country of origin is on the list of eligible countries provided by PayPal. Donors enter their card details directly in the donation form, and credit card charges are processed through the customer's PayPal account. You can read further details on this in our documentation. You need to upgrade to Tamaro version Tamaro version 2.16 or later in order to use this feature. You can request the upgrade via RiaseNow support. While PayPal Vaulting is a pre-requisite for processing one-off card payments through PayPal, we are happy to announce that the automated onboarding-flow for PayPal vaulting is now also available for our Suisse customers. You can find a how-to video of the onboarding-flow in the linked paypal-integration documentation.
While we worked on one-off card payments via Paypal, we also fixed an issue for recurring card payments that caused wrong status transitions in the payment history under certain edge conditions.
Carding-Attack Prevention
Over the last months we´ve implemented several measurements to respond to carding attacks. These measures are to ensure that our systems continue to operate smoothly during the high load situations that are sometimes caused by these attacks. Furthermore, they make it harder for attackers to create successful payment requests. Due to the sensitive nature of this topic, we will not disclose all measures taken, but some include:
- Further data is now handed over to Stripe to make Stripe Radar more effective
- Diverse improvements and implementations in our firewall
- Implementation of challenge and captcha mechanisms
- Implementation of comprehensive fraud metrics and alerts
Payment Agreements
We´ve added further capabilities to the payment agreements feature:
- The payment agreement uuid was added to subscription event(s), in order to better support payment agreements in integrations provided by RaiseNow (RICE). This is also helpful for 3rd party integrations. You can find the updated event example here.
- Support of different subscription flows for payment agreements
- Fixed that the donation purpose was missing in "additional information" on the QR payment slip PDF
- Added missing IBAN, clearing, full name and supporter-uuid in one-off payment agreements
- Added missing payment_source to recurring payment agreements
QR payment slip
- QR payment slips generated for payment agreements now apply the structured address type S based on the data provided by the supporter, in order to adhere to Swiss Payment Standards.
- If a legal_entity is provided for the supporter on the payment or subscription record, the QR payment slip will now prepend this before the supporter’s name.
- The QR payment slip generation now automatically detects whether the touchpoint has a dedicated field for the house number or if the house number is provided together with the street name, and will generate the structured address accordingly.
Bugfixes and small improvements
- Bugfix to prevent that the pre-notification subcription e-mail gets send 4 times in some cases
- Bugfix in order for refunded payments to no longer get a succeeded status again in certain edge cases
- Bugfix to enable updating the custom_parameters object on payment sources
- Bugfix of 500 error from twint_notification_webhook
- Bugfix to prevent invalid status transitions on the payment object caused by delayed webhook processing from twint and a fallback mechanism for ensuring payments have always the correct status.
- Improvement: Support of Polish Zloty currency