December 4, 2023
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
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.)
- Shopping cart: The status message was not visible for Providers
- Order Fee: UI issue with radio buttons solved
October 24, 2023
Support for multi-vendor shopping cart
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.
- 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.
- 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
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.
September 18, 2023
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.
- 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.
- Performance issues solved.
September 4, 2023
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.
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.
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 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
- API getTransactions returned null for transaction state name and tech_name.
August 22, 2023
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.
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.
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
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
- 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.
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.
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.
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 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
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 25, 2023
- 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
- 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 27, 2023
- 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
- 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 9, 2023
- 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 17, 2023
- 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
- 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 20, 2023
- 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
- Added Forward Auction as new transaction type
- Facelifted field type forms
- Facelisted field type table
- Several bug fixes
February 13, 2023
- 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 16, 2023
- Facelisted participants table in Backoffice
- Improving API design
December 5, 2022
- Webhooks performance optimization
- Fixed webhooks sending on participant events
November 30, 2022
- 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
- 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 14, 2022
- Improved API design and leveled up DX
September 12, 2022
- Maintenance and performance improvements
- Multiple bug fixes
August 19, 2022
- 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
- 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 20, 2022
- 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
- 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 16, 2022
- 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
- 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 19, 2022
- 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 27, 2022
- Maintenance and cleanup
April 10, 2022
- 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 23, 2022
- 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
- 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 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.