A marketplace checkout can look like one purchase to the customer while creating several related financial records for the platform. Receiving a customer payment and transferring funds to a seller answer different questions. A database model that compresses both into one paid status can make the platform difficult to explain and operate.
This is a relevant selection problem for marketplaces evaluating OceanBase or another relational platform. The database should support clear relationships between the records, while the application preserves the meaning and authority of each outcome.
Use a specific payment model as the example
Stripe’s separate charges and transfers guide describes a charge on the platform account that is decoupled from transfers to connected accounts. One payment can be associated with transfers to more than one connected account.
That is a particular Stripe Connect model. Other charge arrangements can allocate responsibilities differently, and availability depends on the applicable service conditions. The example should not be generalized into a rule about every payment provider or every marketplace.
Its value for database evaluation is the separation of outcomes. The customer charge explains one part of the relationship. Each transfer has its own identity and result, even when the platform presents a single checkout experience.
Model the relationships the support team must explain
Consider an illustrative marketplace order involving two sellers. The platform needs to connect the customer’s purchase with the relevant seller portions and any resulting transfers. Those relationships should remain understandable if one seller’s part changes.
The model should answer which business allocation a transfer represents, which payment it relates to, and which outcome is currently known. A list of amounts with similar timestamps is a weak substitute for explicit relationships.
The example does not prescribe how proceeds must be allocated or determine legal ownership of money. Those rules need to come from the platform’s applicable business and service arrangements. The database review examines whether the application records and explains the agreed model accurately.
Keep partial progress visible
A customer payment can be recorded while some related transfer work remains incomplete. The platform should be able to show that partial state without describing every related operation as successful.
For example, a support question might concern one seller’s transfer while the customer-facing purchase remains unchanged. The investigation should follow that seller’s relationship and recorded outcome. Reopening the entire checkout as if nothing had happened would lose useful distinctions.
Ask the application team to explain a normal case and a partially completed case using the same business terminology. These are proposed evaluation journeys. They are not instructions to initiate transfers, repeat payment requests, or move real funds during a database review.
Review refunds within the selected service model
Stripe’s guide states that refunding a platform charge in this model does not automatically affect its associated transfers. The platform must account for the related reconciliation separately. This makes the distinction especially important when handling a changed customer purchase.
The application’s records should therefore explain what was refunded and what happened to each related transfer. It should not infer a transfer outcome solely from the existence of a refund record. The actual authorized response depends on the selected service arrangement and the platform’s business rules.
Use a relationship map in the evaluation.
| Record | What it explains | Related question still requiring evidence |
|---|---|---|
| Customer charge | The recorded payment outcome | Which seller allocations does it relate to? |
| Seller allocation | The platform’s agreed business split | What transfer outcome exists for that allocation? |
| Connected-account transfer | A particular transfer and its result | Has a later adjustment changed that relationship? |
| Customer refund | The customer-facing refund outcome | What separate reconciliation is required for transfers? |
This is an authored framework for understanding records. It is not an accounting policy, a settlement schedule, or a determination of contractual entitlement.
Compare databases through the operational questions
OceanBase’s Enterprise product description presents a distributed relational engine relevant to maintaining operational records and their relationships. A marketplace can evaluate the selected application against its required payment, allocation, transfer, and refund states.
Include an investigation across a changed order portion and its related records. The useful result is a consistent explanation supported by the application’s data, not merely a successful query returning a total. A relational transaction inside the platform also does not establish that an external provider completed a transfer.
MySQL, PostgreSQL, and other shortlisted databases should face the same business examples. OceanBase becomes more attractive when its distributed arrangement fits the workload and the team can validate the application’s required behavior. The architecture should not be credited with deciding the marketplace’s financial rules.
Make the final state explainable
The platform should be able to answer the customer’s question and the seller’s question without forcing both into the same status. This allows support and operations to identify the specific unresolved relationship.
A clear model preserves the checkout’s simplicity for customers while keeping the underlying outcomes distinct. That is the database-selection lesson: related money movements need connected records and separate evidence, even when they begin with one purchase.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.