Changelog

Release notes

Remain at the cutting edge by staying updated with the latest features, improvements, and fixes on the randevu.tech · Follow us on LinkedIn ↗

September 2024

September 26, 2024

Enhanced UX with a refined look and feel for authentication pages

You’ll now enjoy a cleaner, more intuitive interface on the Backoffice login page, designed to eliminate distractions. The new look and feel is also streamlined across other authentication pages, such as the Forgot Password and Choose New Password pages.

randevu - new login page

Changelog

  • Refined the login page UI for a cleaner, more intuitive user experience in the Backoffice app.
  • Streamlined the design of the “Forgot Password” page for easier navigation.
  • Simplified the “Choose New Password” page to improve usability and clarity.
  • Resolved an issue where email notification types couldn’t be deleted if email logs existed.

September 22, 2024

Manual adjustment of transaction commercial aspects

Platform operators can now manually modify commercial aspects of transactions until payment preparation. This feature is particularly useful in the MVP phase of cross-border B2B platforms where tax handling isn’t fully automated. Operators can adjust both the tax paid by consumers and the tax retained by the platform from providers, offering greater flexibility in managing tax obligations on both sides.

Manual Adjustment of Transaction Commercial Aspects

Enhanced UX for Platform Revenue Breakdown

The payment details page now features an improved table view for platform revenue breakdown, providing operators with a clear, at-a-glance insight into the revenue generated by each payment. This breakdown includes the platform’s earnings and the total deductions from the provider’s gross order value.

platform revenue breakdown

Changelog

  • Introduced the preparePaymentOnBehalfOf GraphQL mutation, enabling platform operators (Backoffice Users) to prepare payment objects on behalf of consumers.
  • Added the addTransactionCostAdjustmentOnBehalfOf GraphQL operation, allowing platform operators to manually adjust the commercial aspects of a transaction. Adjustments can be made at three levels, each with a distinct scope: supply, provider, and transaction order.
  • Introduced PROVIDER_TAX as a new CostItemKind, representing the amount the platform deducts from a provider’s gross earnings as tax.
  • Enhanced the presentation of the platform revenue breakdown on the payment details page for clearer insights.
  • Added display of chargeable items and order items on the reverse auction method details page.
  • Resolved the issue causing the flow editor to crash when the duration is omitted for scheduling custom events.
  • Fixed a crash on the webhook details page when the webhook’s response is an HTML page.
  • Prevented creation or update of a payment type without selecting a payment method.

August 2024

August 30, 2024

Choose between private and public assets

Platform developers can choose if file field types should be public or private. Previously, all files were private by default, meaning the URL for accessing the asset had to be signed and had a time-to-live of 2 minutes. Public file URLs do not have to be signed and their time-to-live does not expire. Public URLs are mostly relevant for platforms that have open discovery for non-logged-in users a.k.a. guests.

randevu backoffice public and private asset

The Backoffice application introduced the Assets page

Backoffice users can now see all assets uploaded onto the platform at a glance. In addition to file name, ID, and type, platform operators can see further attributes such as link expiry, privacy settings, file size, name, and description.

The GraphQL query for this operation also offers filters. The support for filters in the Backoffice application will be rolled out soon.

randevu Backoffice assets page

Improved UX of the Webhooks page

The Webhook Details page got improved UX. The visual hierarchy has been refined, and the request payload and response have new colors. Additionally, line numbers are introduced for better readability.

randevu backoffice webhook details

Changelog

  • Added Assets page to Backoffice
  • Added support for public files. Platform builder can choose if their files (image or document) should be public or private. Previously, by default, all files were private with a link expiry of 2 minutes. Once the choice for private vs. public files is made, it cannot be changed later.
  • Enhanced the styling of the Webhook Details page
    • group log items by date
    • fix visual hierarchy
    • improved colors for the request’s payload and response
    • introduce line numbers within json
  • Fixed:  the flow editor in the Backoffice showed a “coming soon” label for the configured trigger condition field_value_provided. Rolled out the correct label.

July 2024

July 26, 2024

Dynamic fields allow providers to describe their products in more detail and in a unique way, independent of the supply model

If this option is allowed by a platform owner, providers can now add dynamic fields to their supply instance.

Dynamic fields (sometimes referred as “specific fields”) are the fields providers decided to add during the runtime, and they are not defined by the platform owner.
Example: On a t-shirt marketplace, the platform owner allows shirts to have a name, a size, and a color and allows providers to add additional info about the product.
Supply fields defined by a platform owner (in this case name, size, and color) are
static fields – the platform owner can see those are in their supply type and each t-shirt presented on the marketplace will have those fields.
On the other hand, a
dynamic field is a field that a provider adds when adding/editing one or more of their products. In our example, a provider X decides to add a field showing how heavy the tshirts are (now their tshirts have a name, size, color and weight), whereas a provider Y wants to have the sleeve size (their tshirts have a name, size, color and sleeve size) and a third provider Z doesn’t want any additional fields, so their tshirts fields remain name, size and color.

As dynamic fields are so supply-specific that participants cannot filter supplies by dynamic fields when searching and going through them. To get the maximum flexibility out of the dynamic fields and impose the least amount of restrictions, their input type can only be text.

Dynamic fields come with is_variant_identifier and is_variant_specific attributes, meaning that dynamic fields can also create and define product variants.

This feature is followed by some nice backoffice and import updates. Within the backoffice supply details page, you have now a special section with dynamic fields, making them easier to differentiate from the static ones. Additionally, our data import functionality has been enhanced to fully support the importing of supplies with dynamic fields.

dynamic fields on suppy in randevu backoffice

Deploy to production with an internal release note

Per customers’ requests, we add a release notes section for each live deployment. This new feature offers a comprehensive overview, making it easier than ever to track and understand the updates and improvements included in each deployment. 

Release note for deploy to production in randevu backoffice

Changelog

  • Added dynamic fields & variants
    • Variant field types have two special attributes:
      • is_variant_identifier, is mandatory, unique and each new value “spawns” a fresh new supply instance
      • is_variant_specific, is not mandatory and does not create a new instance
    • InputType for dynamic fields is implicitly TEXT
    • FieldType will be marked as is_dynamic=true and id_parent will be a dummy id of the format DYNAMIC-123…, auto-generated
    • Dynamic FTs will add a prefix to the tech name – dynamic_tech_name, (e.g. dynamic_size)
    • The new dynamic Field has id_parent pointing to the Supply instance
    • This action is for participants only. Backoffice can update the value of dynamic fields.
  • Added last seen timestamp to update participant page on backoffice
  • Extended deploy to production API with new parameter – release notes
  • Fix routing for create order button on the homepage in frontoffice

July 15, 2024

Improved view of the fields

As mentioned in the last release, we started introducing new ways of displaying fields on operational pages inside the Backoffice (Operation Dashboard). In this release, we rolled out the new view also for Transaction, Supply, and Connection pages. Fields are now more intuitive and easier to read, ensuring that you get the information you need at a glance.

Push to production yourself in just 4 clicks! 🚀

Now, randevu users are able to deploy their platform changes from the sandbox to the live environment in self-service.

How? Easy! After completing the configuration of your platform in the sandbox, navigate to the Deployments page. On the Deployments page, click the “Release to Production” button, and confirm the action in the opened dialog after which you can start using your platform in the live environment.

Push to production live deployment self-service

Enhanced variants view in Backoffice

We added new tables for the variants view, enhancing visibility and overall control and manipulation of variants.

supply details randevu new UI

Changelog

  • Introduced cursor-based paginations for APIs for retrieving payments & transfer are leveraging cursor-based pagination.
  • Enabled platform operators a.k.a. Backoffice users to deploy to production via self-service if deployment doesn’t require migrations.
  • Added improved view for operational fields for Supplies, Connections and Transactions.
  • Improved UX of creating Object & Participant Types. Introduced dedicated dialogs that replaced pages.
  • Improved display of supply variants in the Backoffice
  • Fixed SendInBlue with Brevo label inside integration card
  • Forbid enabling supply if a provider has closed account.
  • Forbid duplicate tech name for object types

June 2024

June 30, 2024

Introducing SEPA Payments, out of the box! 🎉

We’re excited to introduce SEPA Payments to our commerce infrastructure = a game-changer for B2B businesses! SEPA (Single Euro Payments Area) streamlines your international transactions across Europe, making them faster, more secure, and cost-effective. With Stripe’s deep integration, SEPA Payments are ready to use out of the box. 

Supercharged the participant section in the operational part of the backoffice

Goodbye clutter, hello clarity! Fields are now more intuitive and easy to read, ensuring that you get the information you need at a glance. We are going to be rolling out this also for all other operation sections.

new participant section display

Additionally, the location input field now includes latitude and longitude coordinates and even comes with a handy Google maps link for pinpoint accuracy and convenience.

These powerhouse updates are crafted to elevate your user experience, delivering a smoother and more enjoyable journey on our backoffice.

Sandbox banner indicating the testing environment

We introduced the new yellow banner at the top of your screen so you can instantly recognize your current environment without a second thought. The banner is only visible in the sandbox environment.

sandbox banner randevu backoffice testing

Changelog

  • Flow actions add_const_to_field, sub_csont_from_field add_field_to_field, sub_field_from_field now support DATE and DATETIME input types
    • DATETIME: value to add (either constant or field values) is an integer meaning seconds
    • DATE: value to add (either constant or field values) is an integer meaning days
  • Added support for equals and not operations for TextField – Field filters
    • equals: String – “Checks if the value is equal against provided value.”
    • not: String – “Checks if the value is not equal against provided value.”
  • Adjusted and extended payment logic to support SEPA payments via Stripe
    • Additionally, transaction types now support multiple payment methods.
    • Revamped payment table; users can now see payment method, payer, timestamps, and more.
  • Added status chips to display error messages on hover, in case of an error.
  • Added client-side validation for image and document fields inside operations
  • Added a new banner for Sandbox mode to help users easily differentiate the environment they are operating in.
  • Fixed UI issue with location field inside operations on Backoffice
  • Fixed CSS for shared objects on Frontoffice

May 2024

May 30, 2024

See what emails were sent to your participants

We’ve introduced a new page in the Backoffice: the Email Logs page. You can now monitor the integration with your Email Service Providers (EMS) and see which emails have been sent, how EMS API responded, what parameters were sent from randevu as well as to whom and when they were sent. The email log retention period is 10 days.

event-logs-page-randevu-backoffice

The email log dialog will open by clicking on one email, showing detailed information about the email sent, including event details, recipients, parameter values, and other valuable information (dialog redesign coming soon)

event logs page details randevu backoffice

Operations dashboard - leveling up the user interface

We introduced the new typography hierarchy and colors inside the operations dashboard. One step/release at a time, the dashboard for platform operators will be getting a new look. Additionally, we have also standardized the styling for tables, including both transactional data and operational data tables. 

Check it out or book a demo call so we can show you the new look & feel!

randevu backoffice design level up

Changelog

  • Introduced a new page in the Backoffice: the Email Logs page. Users can now easily track which emails have been sent from our system and what was the response of an EMS API.
  • Revamped styling throughout the Backoffice application.
  • Fixed supply collection bug. Now, the API always returns the supply_count value instead of returning null.

May 21, 2024

New notification types for triggering and canceling events

Users can now configure email notifications for custom time-based events. For example, you can set up an email reminder when a participant has been in a specific flow state for 24 or any other number of hours.

If the participant leaves this state before the configured 24-hour period ends, you can add a new action to cancel the scheduled email, ensuring it will not be sent. This is easily configured through the flow editor.

Discover transaction providers page introduced on the embedded frontoffice

Once a user configures that consumer participants are allowed to discover providers within their transaction, a navigation item will be displayed in the frontoffice provided by randevu.

On the “Browse Providers” page, consumers can easily filter providers based on their needs. The filters work the same as those for supply browsing in both Single and Multiple direct Transaction type.

Clear separation of tasks inside the backoffice app

As wished by our core customers, we upgraded both the design and the structure of the sidebar navigation inside the Backoffice application and split it into 3 sections.

The first section – starting from Home and going to Bulk imports – holds Dashboard responsibilities. The main users of the Admin Dashboard are the platform’s operations teams interacting with platform participants daily. Since users spend most of their time in operations after configuring their platform, this change aims to improve accessibility and efficiency.

The second section is the Developer console – part of the backoffice application where developers configure, modify, change, and roll out new features of the platform.

The third section represents the Settings space for additional business and tech configurations such as business info, team members, and API users.

See more about the operations dashboard –>

New backoffice side menu look

Changelog

  • Added support for new filters to discoverTransactionProviders EP and introduced cursor-based pagination. The API for filters brings in GQL types and better typing support for developers when working on API clients.
  • Introduced discover transaction providers page on FO
  • Added new flow action type: cancel scheduled event
  • Added new trigger event for notification types – requested_time_event

May 2, 2024

Closing user accounts

As per customers’ request, we are introducing a feature that allows participants to close their accounts on their own. 

Once the participant’s ongoing processes are finished/completed, a participant is allowed to close their account. This can be done through the embedded FO inside Account > Login & security section, or by using the API for customers who use their customized frontend apps.

Closing account randevu

Notification types are extended to support this action, so participants who close their account will receive an email confirmation about it. As everything in randevu, this email is fully customizable.

The platform operators (Backoffice users) can follow the closing of the participant account inside the event log.

closing account randevu events

Filters added on the "Manage supplies" page.

We added filters on the operational page for “Manage supplies” page, so participants can easily filter through their supplies. Supply filters available in the embedded FO are:

  • Enabled: e.g. Supply is onboarded and Active
  • Errors: e.g. Supply is uploaded via bulk import and has some issues
  • Disabled: e.g. Supply is onboarded and Deactivated
  • Onboarding: e.g. Supply is in the onboarding state
  • All: All supplies managed by that participant
supply filters on manage supplies page

Changelog

  • Introduced close account as a participant in self service mode closeMyParticipantAccount (id_participant: ID!, current_password: String!): Boolean. The participant is allowed to close their account if they do not have any ongoing processes on the platform such as transactions, supply onboarding, etc.
  • Added new event participant.closed for notification types
  • Allowed platform operators (Backoffice users) to update current match field accesses inside Single and Multiple direct transactions
  • Allowed platform operators (Backoffice users) to update current connection field accesses
  • Upgraded filter for the mySupplies operation. The filter allows retrieving supplies by their status (e.g. onboarded, onboarding, etc) and by is_active attribute.
  • Fixed showing duplicated transaction items in sidebar navigation on the FO application
  • Adjusted position for search bar on FO landing page

April 2024

April 16, 2024

Discover providers in the embedded frontend

Consumers can now browse providers also inside the embedded frontoffice. The filters for this search can be adjusted in the backoffice by the platform owner.

Discovering providers in the embedded frontend

Changelog

  • Added page on Frontoffice for discovering transaction providers
  • Added Provider filters section inside Backoffice
  • Added discounts, add-ons and taxes on the order level
  • Allowed participant segment fields in pricing calculations
  • Adjusted order-level calculations
  • Adjusted creation of dashboard tiles when the wizard is finished
  • Modified update_fields_access payload for single-direct transaction API
  • Fixed issue with collections

April 3, 2024

Import from excel: decimal values for monetary value fields

When importing monetary value field (e.g. price), the previous version required to enter the value in cents. E.g. to enter 5.19 USD, the user had to type 519. The new version supports entering decimal values and the system performs transformation into cents.

Changelog

  • Added data options when configuring supply import templates
    • date format options
    • decimal separator
    • CSV delimiter
  • Fixed validation for importing supplies via .csv file uploads
  • Improved import templates to support decimal values for monetary value inputs
  • Fixed error message for bulk import
    • Validate image & document URL accessibility
    • Validate image & document URL data format
    • Validate date format

March 2024

March 27, 2024

Change password inside your account settings

A new feature that allows participants to change their password via self-service. Supported for this feature also added to the Frontoffice application.

Password change inside the account settings

When the platform operator changes the participant’s email, the participant has to set up a new password.

In case when the participant changes the email via self-service, no need for a change of the password.

After the password is changed, the system throws an event user.password_updated

Updated dialog for creation of transaction types

Now there is a new dialog for creation of new types in randevu’s backoffice. Check it out.

New transaction type dialog

Changelog

  • Added new endpoint  updateMyPassword(current_password: String!new_password: String!): Boolean! that allows participants to change their password via self-service. Upon changing the password user.password_updated event is thrown. The new password cannot be the same as the current password, has to be at least 8 characters, at least one upper and lower case, one digit, and one special character
  • Added support to the Frontoffice application to allow changing password via self-service
  • Extended the user.email_updated event with new parameters:
    • change password token
    • updated by the platform operator
  • Added new event in events table in BO: user.password_updated
  • Extend notification type parameters with id_parent_transaction
  • Fixed issue with modifying the start value for the auto increments input type

March 14, 2024

Enhanced multi-direct transaction API

The Backoffice application introduced a dedicated page within operations specifically for your multi-direct transactions.

Previously, a dedicated page for single direct transactions was rolled out, we’re now taking steps to streamline a dedicated page for every transaction type. Starting now, operations pages for transactions will be separated for better clarity and ease of use.

When a user creates a new Transaction Type, a corresponding navigation item is automatically added to the sidebar menu. This enhancement provides users with multiple transaction types and a clearer overview of their platform activities.

A similar feature is rolled out to the Frontoffice application, allowing participants to manage transactions of a single type directly on one dedicated page. The goal is to fully replace the previous setup where all transactions were consolidated onto a single page.

This update aims to streamline the user experience by providing participants with a more focused and efficient way to manage transactions. Now, each transaction type has its own dedicated space, offering greater clarity and ease of use.

Changelog

  • Added update for participant segment name via API
  • Added Backoffice support to update participant segment name on their behalf
  • Fixed incorrect error message for connection APIs

March 6, 2024

Enrich import templates

randevu’s infrastructure is now allowing users to enhance and personalize their templates for bulk imports.

This enhancement will offer users greater flexibility and customization options, ensuring a seamless and tailored experience for their specific needs.

Participant segments

A participant segment is a way to group participants into a segment. You can have as many segments as you want and you can also create different segment types.
Example of use: a platform participant wants to create a group of customers to give them specific discounts. That platform participant would create a segment and give it a name, e.g. “VIP Customers”. Afterwards, the participant can add e.g. 10% discount to participants within a segment or define other segment conditions.

participants segment randevu

Changelog

  • Added new flow action – delete_field_value
  • Added new flow action – add_field_to_field
  • Added new flow action – sub_field_from_field
  • Added new flow action – add_const_to_field
  • Added new flow action – sub_const_from_field
  • Added new flow action – create_order
  • Added new flow condition – field_value_equal_to_field_value
  • Added new flow condition – field_value_not_equal_to_field_value
  • Added new flow condition – field_value_greater_than_field_value
  • Added new flow condition – field_value_less_than_field_value
  • Added new flow condition – field_value_greater_than
  • Added new flow condition – field_value_less_than

February 2024

February 27, 2024

Enhanced single direct API

We’ve introduced a dedicated page within operations specifically for your single direct transactions.

In response to feedback from some of our clients regarding the usability of the transactions page, we’re now taking steps to streamline the experience. Starting now, operations pages for transactions will be separated for better clarity and ease of use.

When a user creates a new TT (Transaction Type), a corresponding item will automatically be added to the sidebar menu. This enhancement provides users with multiple transaction types and a clearer overview of their platform activities.

We’ve implemented a similar feature in Frontoffice, allowing participants to manage transactions of a single type directly on one dedicated page. We aim to fully replace the previous setup where all transactions were consolidated onto a single page.

This update aims to streamline the user experience by providing participants a more focused and efficient way to manage transactions. Now, each transaction type has its own dedicated space, offering greater clarity and ease of use.

Changelog

  • Added new NT parameter connection.id for all connection-related events
  • Fixed target object in multiple direct transaction top-level flow for copy_field_value action
  • Fixed issue where participant couldn’t download job reports and data files on mobile device

January 2024

January 24, 2024

Bulk import

This functionality eliminates the need for manual entry, particularly beneficial when creating hundreds or thousands of listings (supplies) at once.

Platform owners and providers can effortlessly streamline the onboarding process. Platform owners can enable bulk imports and create customizable templates for importing data, while providers themselves can take advantage of these features.

Key features:

  • Bulk Imports: Upload listing in bulk using .csv files, saving valuable time and effort.
  • Customizable Templates: Enable/disable templates as needed, providing flexibility and control over the import process.

Providers managing the bulk import inside Supply Type.randevu backoffice bulk upload template types

Once template is created and activate Providers are free to start importing.randevu frontoffice manage supplies upload possibility

Providers also can decide are newly imported supplies activated by default or not.randevu frontoffice selecting whether products are automatically uploaded

Platform team members can import supply on behalf of providers through Backoffice application.platform team members imports supply on behalf of providers.png

Support for connection fields

We added support for connection fields to be used in match price configuration.

Example of usage:

  • Personalized discounts
  • Personalized terms between parties

Changelog

  • Added new email templates for inviting platform operator’s team members.
  • Updated default email template for the platform owner account.
  • Improved Backoffice dashboard UI for sandbox and live environment.
  • Updated currencies are now available. Besides EUR we are now supporting USD, GBP & AUD.
  • Improved way of creating test users for all participant types.
  • Added better error messages for API users.

December 2023

December 28, 2023

Collections

  • Supply collections facilitate enhanced management of providers’ inventory by effectively organizing supplies. Providers are now able to group supplies by collections.
    For example, shoes can have different collections: Run, Skate, and Casual, summer or winter collection…Changelog - Providers can group their supply by collections
  • Consumers now can also discover supplies by collections.Changelog - Consumers can discover supplies by collections

Referrals

  • Allow pre-populating participant’s Fields before their email has been validated (API for now)
  • Allow Participants to “invite” other Participants by initiating the signup process and even pre-populating new Participant’s fieldsChangelog - Referrals

New email parameter and discovery configuration

  • A new parameter is now available: platform.name
    Changelog new parameter
  • Restrict discovery only to participants with whom an established connection exists.
    Example: Provider A has 3 supplies. Consumers need to establish a connection with Provider A to browse his/hers supplies. Changelog restrict discovery

Changelog

  • Added options for providers to group supplies by collections.
  • Added option for consumers to discover supplies by collections.
  • Enabled pre-populating participant’s fields before their email has been validated (via API)
  • Allowed participants to “invite” other participants by initiating the signup process and even pre-populating fields of new participants
  • Allowed all participant types to create shared objects
  • Removed limitation which allowed only participant type providers to create Shared objects.
  • Added new parameter for Notification types: platform.name.
  • Added default email now available user.email_updated. When the user’s email is updated by the participant or backoffice, the User will receive an email.
  • Enhanced default email notification types are to contain platform.name.
  • Enhanced transaction type details page to show transaction type tech name.
  • Added field types for Connection Types
  • Added options for users to accept/decline connections manually
  • Added option for Backoffice to reject or decline the connection
  • Allowed configuring notification types and webhooks to be triggered by connection events
  • Enhanced discovery to restrict the result set only to participants with whom an established connection exists.
  • Fixed conditional rendering for fields inside Object at Frontoffice application.

December 4, 2023

Changelog

Events log

The Backoffice applications let you see the log of fired events. To see the log go to Developers → Logs in the BO application. The log retention period is 7 days.

Stripe dashboard for connected account via frontoffice

Your provider participants have to open a merchant account at one of the Payment Service Providers to receive the money from your platform. As randevu already has integration with Stripe’s Connected Account (Express), the FO application now supports redirecting Stripe’s dashboard from the Payments & Transfers page.

Manually request payout from merchant account

Provider participants can now manually request a payout from their merchant account. At this time, the supported merchant account is Stripe Connected Account.

To manually request the payout, go to Payments & Transfers page at the FO application.

New input type: SmartTextSet

Field types now support SmartTextSet input type.

Change the user’s email

New API endpoints to change user’s email. You can change the user’s email via the Backoffice application or let the user change the email in the self-service mode. After the email is changed, user.email_updated event is fired.

Email Notification Types: recipients can be SmartText & SmartTextSet fields

This will allow users to add recipients from the field. Supported fields have input type SmartText & SmartTextSet with the pattern set to “email”.

Email Notification Types: email parameters can be set as values coming from the event payload

This will allow users to extract an event payload value as a parameter for an email notification.
Example: “new_email” and “old_email” from the event user.email_updated

Improvements

Match config is now in sync with the Transaction Type.
Example: If you create a parameter in Match Configuration aka Commerce Configuration, it will be instantly added to Transaction Type. (MT and/or MTT containers depend on the transaction.)

Bug fixes

  • Shopping cart: The status message was not visible for Providers
  • Order Fee: UI issue with radio buttons solved

October 2023

October 24, 2023

Changelog

Support for multi-vendor shopping cart

Shopping cart is well well-known concept in the world of e-commerce. In the world of platforms and marketplaces, single-vendor and multi-vendor shopping carts exist.

In essence, a multi-vendor shopping cart allows you a unified checkout experience of products and services from different providers at the same time. The marketplace platform is able to properly route orders, calculate the total chargeable amount, properly handle payment (pay-in), transfers & payouts, consider terms that each individual vendor might have (e.g. 15% commission vs 7% commission), etc.

Recall that every value exchange process among participants of a platform is a transaction. Therefore, multi-vendor shopping cart is another transaction type on randevu named multi_direct.

Participant reference field type

Field types got new input kind participant. This allows platform architects to model behaviors such as managing lists of “favorite buyers”, “favorite sellers” and similar.

Improvements

  • Displaying the value of conditional fields improved. If there is no value present for a conditional field, randevu will hide the field from the view.
  • The performance of the matching algorithm for reverse auction transaction types is improved
  • Match configuration, an object controlling the commerce behavior of a supply, can now disable the pricing feature if the pricing is not required within the transaction. E.g. transaction on Tinder does not include pricing. Platforms that do not use pricing can simply turn off pricing in match configuration and all pricing elements on our FO will be hidden. Elements such as “price summary”, “supply price” and so on.
  • Filters for documents and images: while discovering supplies, you can now filter only supplies that have an image/document
  • The frontoffice displays the URL for the “Support” in the footer. The value for the URL is configured via randevu Backoffice.

Bug fixes

  • Consumer and provider messages are now available when the transaction is in a terminated state.
  • The unlimited option for the number of maximal created matches is fixed.

October 2, 2023

Changelog

Frontoffice application supports custom domains

randevu’s frontoffice application was previously only accessible via domains managed by randevu.

Now, randevu customers can bring their own domain (example: www.myowndomain.com) and use it to access the frontoffice application.

Bug fixes

Frontoffice applications show the correct error page if you try to open them in the live environment without previously deploying the backend to production.

September 2023

September 18, 2023

Changelog

Frontoffice gets new features and improvements

  • Users are now able to configure external links to be embedded in the Frontoffice application. For example, URLs for Terms, Privacy, Imprint, Facebook, etc.
  • Configuration of the landing page now allows you to hide or show desired sections such as How it works, About us, Unique Selling Points, etc.

    randevu smart text features

Improvements

  • SmartText field types improvements
    • URL is now clickable and it opens in a new tab in the existing browser window.
    • Email: When a user clicks the email link, it opens the default email client installed on the user’s machine.
  • Discovered supply card improvements
    • Cards now only display specific fields: Image, Name, Description, Price & Variants. Any other field will not be displayed.
  • API Improvements
    • The endpoint getTransactions now includes pagination.

Bug fixes

  • Performance issues solved.

September 4, 2023

Changelog

Transfers

Transfers are movements of funds from the platform account to the merchant account. A merchant account is an account that a provider has to open at a payment service provider.

When the funds arrive at the merchant account, they are legally belonging to the provider.

Note: Do not confuse transfers and pay-outs. Transfers are fund movements within a PSP while pay-outs are fund movements from a merchant account out of a PSP (for example from merchant account at Stripe to provider’s bank account).

The transfers can be manually executed, immediately, or scheduled. Manually means that the marketplace operator is responsible for manually sending each transfer or marking it as successful if the transfer is happening off the platform.
Example: Platform operator sending bank transfer from platform’s bank account to provider’s bank account instead of transferring funds from platform-account to merchant-account.

randevu backoffice screenshot showing the transfer

Each order reflects exactly one transfer. The transfer amount reflects the order gross value deducted by all provider-facing platform fees. Recall that those provider-facing platform fees can be both from order-level and supply-level.

Each provider can see all platform fees that are related to each order.

randevu backoffice screenshot showing the transfer succeeded

SKU-based availability

Besides all the commerce configuration, match configuration now also supports SKU-based availability.

This allows tracking of in-stock and out-of-stock for each supply including supply variants. The availability is automatically managed for you by randevu.

Improvements

  • Improvements on payment type and payment type dialog
    • Tech name added to payment type
    • Obsolete fields are removed from payment type dialog.
  • Two new events introduced in Transaction type flow

Bug fixes

  • API getTransactions returned null for transaction state name and tech_name.

August 2023

August 22, 2023

Changelog

Payments

The payments take the chargeable object and create a charge for it. The chargeable object provides a complete breakdown of items that lead to total_to_charge.

When using Stripe’s Checkout to check the payment, you can see the breakdown of the chargeable including the discounts, taxes, and consumer-facing platform fees.

The system now exposes payment.authorized and payment.captured events. payment.authorized means that the platform obtained the right to take the funds from the consumer’s payment method. On the other side, payment.captured means that the funds arrived on the platform account.

These two events could happen immediately after each other or it could take days, even weeks between these two events. How long it takes, depends on the payment method which was used.

Payments in Backoffice

In the marketplace backoffice, you can now see all the payments and filter them by different payment’s lifecycle status such as payment.authorized and payment.captured.

randevu backoffice payments overview

You can also see the details of payment such as the actual cost of payment processing, platform revenue items, GMV and revenue per transaction, etc.

randevu backoffice screenshot platform revenue breakdown

Orders and automatic calculations

Upon payment being captured, randevu creates orders and automatically calculates platform revenue items as well as the provider’s gross and net revenue.

August 15, 2023

Changelog

Chargeable covers advanced pricing, add-ons, discounts, and taxes

Every supply type has a match configuration type which defines the commerce rules of the supply. The match configuration consists of

  • pricing
  • add-ons
  • discounts
  • taxes
  • restrictions
  • platform fees targeting both consumer & provider

The pricing module allows ultimate flexibility by allowing you to create your own pricing rules. The pricing rule engine depends on the fields of supply, availability parameters, and custom parameters.

Add-ons

You can model supply’s add-ons. For example, cleaning service as an add-on to the accommodation that is being booked. Pick-up fee to that provider charges, etc.

Discounts

The module allows you to create your own discount rules. These discount rules can be marketplace-wide as well as at the provider level.

Example: You can say, if someone is purchasing 10 quantities of an item, then they will get a 10% discount. Or you can let every provider define their own quantity-based discount.

Example: One provider will offer a 5% discount if you buy more than 3, another one will give 10% off if you order more than 10, yet another provider will not offer a discount at all. This is an example of a quantity discount, though you get the freedom to model different kinds of discounts that suit your marketplace and industry.

Taxes

You can include and define tax items at the level of a supply and let providers choose if they want taxes to be collected. The tax can be VAT, Sales tax, or whatever. You have the freedom to include multiple tax items if required.

Restrictions

Restrictions are another rule-based module that allows you to model conditions that restrict the commerce of a given supply.

Example: you can say marketplace-wide, your purchases are allowed below 50€. You can also let providers have their own restrictions. E.g. one provider will say it does not take orders below 100€, while another one will say that they do not take orders below 500€.

The restrictions can also be of non-monetary nature. The provider offers accommodation has a restriction of max 4 guests.

Platform fees for both consumers and providers

At the supply level, you can also model platform fees – both fixed-amount as well as commission ones. These fees are considered platform revenue items.

As a platform, you can make revenue both from consumers and providers.
Example: If a consumer is purchasing a “non-eco-friendly” item, you can charge them a fixed platform fee of 2€.

From the provider side, you can create category-based, product-based, or whatever-based fees. Also, the fee can also be fixed amount or commission-based.
Example: You can take 4% commission for products from category A and 7% for products from category B. You can also combine multiple fees at the same event. E.g. 7% commission plus 1€ fix-fee.

Order-level platform revenue items

Beside the supply-level platform fees, you can also have order-level platform fees aka platform revenue items.
Example: you can at order-level create a “booking fee” for a consumer of 2€. These 2€ will increase total_to_charge that consumer pays. For the provider, you could say 5% of the order-value for payment processing.

August 1, 2023

Changelog

Shared objects

Public shared objects: Now, all users on the platform can access shared objects marked as public.
Example: Participant wants to add a venue where activity is happening. All added venues will be available for all platform users.

Scoped shared objects: Shared objects are set to private by default, limiting access only to their creator. However, through custom flows, you can now control who else can view these objects. This provides greater flexibility in managing shared content amongst participants.
Example: User A wants to create a list of company contact persons. This list is private and only visible to User A. However, during a transaction, User A has the option to add a “company contact person” to the transaction, making that particular contact visible to the other party involved in the transaction.

July 2023

July 25, 2023

Changelog

  • Exposed new events: transaction.terminated, transition.forcedly_terminated
  • Added new flow actions: force_transition, request_time_event
  • Added new transition trigger requested_time_event
  • Filtering for date set and multi select is improved
  • Flow editor improved how condition trigger is displayed

July 10, 2023

Changelog

  • Calculate total price before starting a transaction via calculcateSupplyPrice API endpoint
  • Introduced shared objects to Frontoffice
  • Allow providers to override total transaction amount
  • Added Provider’s public page to the Frontoffice

June 2023

June 27, 2023

Changelog

  • Introduced Shared Objects concepts (API only)
  • Introduced advanced pricing configuration
  • Introduced match restrictions
  • Introduced new input type: DateSet
  • Added AccountPage to Frontoffice
  • Include match id within payload od transaction events
  • Facelift of TransactionType page on Backoffice

June 8, 2023

Changelog

  • Added to Backoffice option to create supply on behalf of provider
  • Added variants to supply type
  • Added textSet field type
  • Added smartText field type that supports emails and URLs
  • Added UI config of field types that is used by Frontoffice. You can now control labels and helper texts of field inputs
  • Facelifted MyTransactions page on Frontoffice
  • Added more granularity to purganing sandbox data. You can now keep subset of data (e.g. participants)
  • Facelifted Participant details page on Backoffice
  • Facelifted Supply type details page refactored on Backoffice
  • Facelifted Participant type details page on Backoffice
  • Facelifted Transaction details refactored on Backoffice
  • Facelifted Reauthentication dialog refactor
  • Added min-max input option for ObjectSet, ImageSet, and DocumentSet
  • Account update fixes
  • Prevent user from adding autoinc field to object and objectset

May 2023

May 9, 2023

Changelog

  • Allow Backoffice users to see when a user logged in last time
  • Exposed transaction.initiated and transaction.prepared events
  • Added new variables for email notifications for transaction.state_reached event
  • Allow deep linking into sandbox and live environments in Backoffice
  • Aligned API endpoints to GraphQL conventions
  • Facelifted participant onboarding page on Frontoffice
  • Email notification types page refactored (BO)

April 2023

April 17, 2023

Changelog

  • Added configuration for Frontoffice pages Landing page, authentication pages and profile page
  • Allow through Backoffice to update participant’s field access to its own data and to its supplies
  • Under the hood work to enable team mode a.k.a. organizations as a participant
  • Show non-started transactions in Backofice
  • Facelifted MyConnectionsPage on Frontoffice
  • Facelited dashboard tiles on Frontoffice
  • Several bug fixes

April 3, 2023

Changelog

  • Allow to activate and deactivate a supply instance
  • Allow match requester to terminate transaction
  • Improved UX of flow editor 🔥
  • Exposed tech_name for States and Transitions

March 2023

March 20, 2023

Changelog

  • Added ConnectionType concept
  • New deployment process including flow migrations – push to prod
  • New email notification trigger for the event transition_executed
  • Several bug fixes

March 6, 2023

Changelog

  • Added Forward Auction as new transaction type
  • Facelifted field type forms
  • Facelisted field type table
  • Several bug fixes

February 2023

February 13, 2023

Changelog

  • Introduced scheduler to control matching tool
    • Added time-to-live and auto-deactivation of a matching tool
    • Control TTL to be custom or fixed
  • Control how much matches tool is allowed to create and close
  • Execute matching strategy on new supply is created
  • Design and layout improvements on Backoffice
  • BO participant table

January 2023

January 16, 2023

Changelog

  • Facelisted participants table in Backoffice
  • Improving API design

December 2022

December 5, 2022

Changelog

  • Webhooks performance optimization
  • Fixed webhooks sending on participant events

November 2022

November 30, 2022

Changelog

  • Added new input type: auto increment
  • Added environment variables that can be configured via Backoffice and used in e.g. email notifications
  • Performance execution improvement of updating field accesses.
  • Several bug fixes

November 10, 2022

Changelog

  • Introducing ObjectType
    • Object input_type is custom container of field_types
    • ObjectSet input_type can carry multiple Objects inside
  • Introduced tech_name to level up DX
  • MatchingOrder configuration improvement

October 2022

October 14, 2022

Changelog

  • Improved API design and leveled up DX

September 2022

September 12, 2022

Changelog

  • Maintenance and performance improvements
  • Multiple bug fixes

August 2022

August 19, 2022

Changelog

  • Resend verification email from BO
    • Allow BO users to re-send email verification email to Participants
  • New event type exposed: participant.email.verification_requested
  • Reauthentication dialog improvement for Backoffice application
  • Several bug fixes

August 5, 2022

Changelog

  • New API for provider supplies
  • Allow participants to see all provider’s supplies
  • Auto-transitions now available for Transaction Type
    • User now can add auto-transitions in Flow Editor
  • Transfers added to operations
  • New event types for webhooks and notification types (state reached in participant and supply)
  • Facelift FO: unavailable photo placeholder
  • Field document_set now improved on FO
  • Validation for field_type multi-select fixed
  • Sub transactions properly emits state_reached event
  • Fixed field type order

July 2022

July 20, 2022

Changelog

  • Introduced onboarding flows for participant
  • Introduced onboarding flow for a supply
  • Enable provider’s onboarding to Stripe’s merchant account (Connected account)
  • Several improvements at flow editor
  • Facelifted discovery page at Frontoffice
  • General styling improvements on Frontoffice
  • Several bug fixes

July 1, 2022

Changelog

  • Provider fields for discovered Supply
    • Frontoffice now shows provider fields at supply card 🚀
    • Backoffice: New section to adjust visibility of provider fields at Supply card.
  • Deleting of transactional data in the sandbox environment
    • Allow marketplace operator to clear all dummy/test transactional data created in Sandbox environment.
  • Added MyProfilePage to frontoffice that allows to preview and my update my fields as logged in user
  • Transaction.state_reached now available for email notification types 📤
  • Custom payment types available and fully functional
  • Adjusted and improved way of creating a supply instance.
  • Bug fixes with Location input type
  • Bug with update_field_access now fixed

June 2022

June 16, 2022

Changelog

  • Email Notification Types
    • Custom notification type available for participant.created event
    • Custom notification type available for participant.password.reset_requested event
  • Several bug fixes 🔨

June 7, 2022

Changelog

Transactions API 2.0
  • Added subtransactions 🚀
  • Facelifting of Operations Participants page
  • Facelifting of Operations Supplies page
  • Facelifting of Operations Transactions page
  • Facelifting of Operations Payments page
  • Fixed bug with setting min/max values in Field Type
  • Fixed bug what crashed flow editor in one edge case

May 2022

May 19, 2022

Changelog

  • Added email notification types
  • Added email notifications page in Backoffice
  • Added default email notifications
  • Added integration with SendInBlue for email notifications
  • Integrated Stripe as payment service provider
  • Payment types
  • Improved Participant details page in Backoffice
  • Improved Supply details page in Backoffice
  • Improved API design for the endpoint to verify participant account
  • Frontoffice validates integer inputs

April 2022

April 27, 2022

Changelog

  • Maintenance and cleanup

April 10, 2022

Changelog

  • Added controlled data disclosure for discovery APIs
  • Configure what fields are visible to participants and what to guest users (non-logged in users)
  • Integrated Stripe as payment service provider
  • Facelifting integrations page in BO
  • Facelifting navigation menu in BO
  • Properly set order of fields in supply type, participant type, match type and matching tool type
  • Frontoffice properly shows input options of a field type
  • Removed bug when Frontoffice edits geo-based field type

March 2022

March 23, 2022

Changelog

  • Added section in Backoffice to control the Frontoffice application
  • Added global section
  • Added landing page section
  • Multiple improvements on marketplace wizard
  • Added new design for wizard
  • Removed unnecessary steps
  • Multiple Frontoffice improvements
  • New layout and design for MyTransactionsPage
  • New design for MyTransactionDetailsPage
  • Added new API docs
  • Improvements in Supply onboarding
  • Improvements in Participant onboarding
  • Fixed a bug with the total amount on Payments Page in Backoffice.

March 17, 2022

Changelog

  • Backoffice shows all payments: Operational team can now track all payments happening on the marketplace. You can find this page under the Operations section within the Backoffice application.
  • Several flow editor improvements.
  • API return next possible steps
  • UI config to show state related message to a consumer and provider
  • Multiple design improvements on Frontoffice
  • Changed default states in transaction types
  • Fixed bug when adding a transition triggered by manual API call
  • Fixed bug with incorrect info email address

February 2022

February 14, 2022

First randevu.tech release 🎉

The release contains 4 big components

Backoffice application/admin panel. Place for marketplace owners and their operational team to perform daily operations, approving participants, verifying listings, monitoring transactions, etc. Find out more about the admin panel –> 

Frontoffice application. Default frontend you that allows your marketplace participants to sign up, create listings, perform transactions, etc.

Backend API. API endpoints used to add custom integrations and extensions in side-by-side manner.

Marketplace API. API endpoints that are used by your custom frontoffice frontends (web, mobile or desktop) and also by randevu’s frontoffice.