Integration Patterns

Integration patterns define how your ERP system exchanges data with Jodo. Choose the flow that best matches when data becomes available, who starts the payment journey, and how much control your system needs over checkout.

Most integrations use one primary pattern, but products can still share common building blocks such as Student APIs, User APIs, platform redirects, and webhooks.

↓ Customer intent

Pull Integration

Jodo fetches required details from your system when a customer starts a payment journey. Use this when your ERP should remain the source of truth at checkout time.

Explore pull flow → ↗ Hosted checkout

Order Integration

Create a payment order first, then send the customer to a hosted checkout. Use this when you want a clear payment request without modelling a student or fee schedule.

Explore order flow → ↔ Real-time sync

Push Integration

Push student, fee, and payment context to Jodo as changes happen. Use this when your system can proactively keep Jodo synchronized.

Explore push flow →

How to Choose

Requirement	Recommended Pattern
ERP should remain the source of truth and Jodo should fetch latest student or fee data when required.	Pull Integration
ERP can create and update student, fee, and user records in Jodo ahead of time.	Push Integration
Payment should be collected for an event, application, registration, or other ad-hoc purpose without first creating a student record.	Order Integration
Your app needs to open a hosted Jodo flow after creating or fetching a redirect URL.	Pair the chosen pattern with the relevant Platform guide.

What Stays Common

• API requests must use the correct environment and authentication credentials.
• Webhooks should be configured for final payment, subscription, loan, or order status updates.
• Callback URLs should be treated as user-navigation signals, not as the final source of payment truth.
• Your backend should reconcile status using APIs and webhooks before updating financial records.