will be documented and the core code underlying this area may change from version
to version.
An 'order' is our developer term for a pseudo-entity that maps to the CiviCRM contribution object but also encompasses related entities like memberships, event registrations and underlying financial entities. There is no single 'order' table but the top level order information is stored in the civicrm_contribution table.
An 'order' is our developer term for a pseudo-entity that maps to the CiviCRM contribution object but also encompasses related entities like line items, memberships, event registrations and underlying financial entities. There is no single 'order' table but the top level order information is stored in the civicrm_contribution table.
The Order API is intended to be used as the primary API for adding, updating, and deleting orders. When using the order api you should
1. Rely on the Order API to create related objects like like memberships and event registrations. (Don't pre-create them)
1. Rely on the Order API to create related objects like line items, memberships and event registrations. (Don't pre-create them)
2. Always create orders in a pending state (unfortunately you need to pass contribution_status_id = Pending in for historical reasons).
3. Expect the status of contribution and any related memberships or event registrations to be Pending.
4. Call Payment.create to record any payments that have been made against the order.
5. Rely on adding payments to transition any relate entities to completed.
You should NOT
1. Pre-create line items memberships or event registrations
1. Update the status of an order to Completed using any method OTHER than adding payments to it (Payment.create api)
