Download the PHP package sequra/integration-core without Composer

On this page you can find all versions of the php package sequra/integration-core. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of sequra/integration-core

Informations about the package integration-core

SeQura Integration Core Library

Table of Contents

📘 Overview

What is the SeQura Integration Core?

The sequra/integration-core library is a platform-agnostic PHP library that provides the foundational business logic and API communication layer for integrating SeQura payment methods into any e-commerce platform. It is built following clean architecture principles, ensuring that the payment processing logic remains centralised and consistent across implementations.

One of the main goals of the library is to provide this shared, centralised logic, while still allowing for customisation and extension to adapt behaviour and structure to different systems. At the same time, it avoids dependencies on system-specific or third-party components, relying only on pure PHP and vanilla JavaScript to keep the core flexible, lightweight, and portable.

The library is designed with the following non-functional requirements, which are to be consistently upheld across all SeQura integrations:

These attributes are not just desirable qualities, but mandatory design goals that ensure long-term maintainability and alignment with SeQura’s architectural principles. They represent core priorities, though not the entirety of the non-functional requirements defined for the CORE. For a complete overview, refer to the architectural documentation, which describes in detail how these and other quality attributes shape both the design and implementation of the system.

Problems Solved by Integration Core

Architectural Overview

To ensure maintainability and alignment with clean architecture principles, the integration-core library separates responsibilities into distinct layers, following the Onion Architecture model.
This structure avoids mixing concerns, keeps the core logic centralised, and ensures consistency across all SeQura integrations.

CORE – Infrastructure

Provides the technical foundation to support business logic, ensuring consistency and portability across platforms:

CORE – Business Logic

Encapsulates SeQura’s domain logic, centralized and reusable across all platforms:

Integration Interfaces

Defines extension points that allow business logic to interact with diverse e-commerce systems without leaking system-specific dependencies.

Concrete Integrations

Implements shop-specific adapters and extensions, bridging CORE with the host platform:

🛠 Installation

Requirements

Installing via Composer

Developer guide

If you are planning to contribute to the development of this library, please refer to the Developer Guide for instructions on setting up your development environment, debugging, and running tests.

🚀 Quick Start Guide

The library uses a bootstrap pattern for initialization. This step must be performed after installing the library.

Its main goal is to ensure independence from the dependency injection (DI) mechanisms of different systems, and to provide a way for services to be overridden or extended in concrete platform integrations.

The dependency inversion principle is applied here as a best practice to achieve this flexibility, but it is not the primary objective of the bootstrap process.

This library provides a BootstrapComponent class that should be extended by the platform integration. The BootstrapComponent is responsible for registering all required services, repositories and dependencies.

Before going deeper into the BootstrapComponent, let's see take a quick look at the concept of Services, Repositories and how to register them.

Services

Services are intended to handle use-cases. The way you should use to register a new Service is through the SeQura\Core\Infrastructure\ServiceRegister class. The following example shows how to register the implementation for the SeQura\WC\Services\Core\Encryptor service required to encrypt and decrypt text.

For retrieving the instance, use this method instead:

Repositories

Repositories define a way to read and write data to a datasource (like a database) and map raw data to entities. They must implement SeQura\Core\Infrastructure\ORM\Interfaces\RepositoryInterface. The integration-core provides for this the SeQura\Core\Infrastructure\ORM\RepositoryRegistry, similar to the service alternative.

To register a new repository implementation, see the following example:

To retrieve a repository:

Using the BootstrapComponent

To use the BootstrapComponent, extend it in your platform integration and implement the init method to register all required services and repositories. Here's an example for a Magento 2 integration:

After implementing the Bootstrap class, you can call Bootstrap::init() in your platform's bootstrap process to initialize the integration core library.

Here are the essential components your bootstrap implementation must provide:

Core Infrastructure Services (Required)

These services must be implemented by every platform integration:

1. Configuration Service

2. Logger Service

3. Encryptor Service

Business Logic Services (Required)

4. Store Service

5. Version Service

6. Category Service

7. Product Service

Order Management Services (Required)

8. Order Creation Service

9. Merchant Data Provider

10. Order Report Service

Integration Services (Required)

11. Selling Countries Service

12. Disconnect Service

Widget Services (Optional but Recommended)

13. Widget Configurator

14. Mini Widget Messages Provider

Repository Registrations (Required)

Your bootstrap must also register repositories for entity persistence:

Minimum Implementation Checklist

✅ Infrastructure Layer

✅ Platform Integration Layer

✅ Order Management Layer

✅ Business Services Layer

✅ Data Persistence Layer

✅ Optional Enhancement Layer

This comprehensive list ensures your platform integration provides all necessary components for the SeQura Core library to function properly across all supported use cases.

📦 Platform Integration Examples

You can take a look at existing implementations of the integration-core library in the following repositories:

📚 Public API Documentation

Architecture Overview

The Core will be implemented by following the onion architecture comprised of multiple concentric layers interfacing with each other towards the core that represents the business logic, as displayed in the diagram below. Onion Architecture is based on the inversion of control principle where inner layers' dependencies are abstracted as required interfaces:

The library structure is organized the following way:

Infrastructure Components

The Infrastructure Components form the foundation of any SeQura integration, providing essential services for logging, HTTP communication, configuration storage, task execution, and data persistence. Understanding and properly implementing these components is critical for a robust, scalable integration.

Overview

The infrastructure layer follows Dependency Inversion Principle and uses Abstract Factory Pattern to provide platform-agnostic implementations of core services while allowing platform-specific customizations through interface implementations.

Core Infrastructure Components

1. HTTP Client Infrastructure
2. Logging Infrastructure

Implementation example based on Magento 2:

3. Configuration Infrastructure

Implementation example based on Magento 2:

4. Task Execution Infrastructure
5. ORM Infrastructure
6. Regex Provider Infrastructure

If you're using the Integration Core UI library you must provide the regular expressions for validating user input in the admin panel when the SequraFE object is initialized. The RegexProvider service provides a function toArray() for this purpose. Example:

Key Infrastructure Benefits

  1. Reliability: Comprehensive error handling and retry mechanisms
  2. Security: Encryption, secure defaults, audit logging
  3. Performance: Caching, connection pooling, resource monitoring
  4. Scalability: Distributed processing, load balancing capabilities
  5. Monitoring: Detailed metrics, health checks, alerting
  6. Maintainability: Structured logging, configuration management
  7. Flexibility: Platform-agnostic interfaces with custom implementations

Infrastructure Best Practices

  1. Error Handling: Implement comprehensive error handling with appropriate retry logic
  2. Security: Encrypt sensitive data, use secure defaults, audit all changes
  3. Performance: Monitor resource usage, implement caching strategies
  4. Reliability: Use transactions, implement health checks, monitor system health
  5. Observability: Implement detailed logging and metrics collection
  6. Configuration: Validate all configuration, provide migration paths
  7. Testing: Test infrastructure components thoroughly with realistic scenarios

Admin API Layer

The AdminAPI layer in the SeQura integration-core library provides a standardized interface for platform integrations to interact with SeQura's administrative functionalities. It serves as the primary entry point for all admin panel operations, offering a clean separation between business logic and platform-specific implementations.

Overview

The AdminAPI layer follows a Controller-Service pattern with Aspect-Oriented Programming (AOP) for cross-cutting concerns like error handling and store context management.

Core Components

1. AdminAPI Main Class
2. Controllers (9 Main Controllers)
ConnectionController
PaymentMethodsController
GeneralSettingsController
CountryConfigurationController
PromotionalWidgetsController
OrderStatusSettingsController
TransactionLogsController
DisconnectController
DeploymentsController
3. Aspects (Cross-cutting Concerns)
ErrorHandlingAspect
StoreContextAspect
4. Request/Response Objects

Practical Example: General Settings Management

Here's a comprehensive example showing how the AdminAPI is used in a Magento admin controller:

Checkout API Layer

The CheckoutAPI layer in the SeQura integration-core library provides customer-facing functionality for the checkout process and promotional widgets. Unlike the AdminAPI which handles backend configuration, the CheckoutAPI focuses on real-time customer interactions during the shopping experience.

Overview

The CheckoutAPI follows the same Controller-Service pattern with Aspect-Oriented Programming (AOP) as the AdminAPI, but is optimized for frontend performance with caching mechanisms and validation layers.

Core Components

1. CheckoutAPI Main Class

2. Controllers (3 Main Controllers)

SolicitationController

Use Case: When a customer reaches checkout, this controller determines which SeQura payment options are available based on cart contents, shipping address, and merchant configuration.

CachedPaymentMethodsController

Use Case: Instead of making API calls on every page load, this controller serves cached payment method data, improving checkout performance.

PromotionalWidgetsCheckoutController

Use Case: Displays SeQura promotional messages and financing options on product pages, category pages, and cart to increase conversion rates.

3. Built-in Validation

The CheckoutAPI includes comprehensive validation layers:

4. Request/Response Objects

Practical Example: Product Page Widget Integration

Here's a comprehensive example showing how the CheckoutAPI is used in a Magento product page:

Practical Example: Payment Method Solicitation

Here's how checkout payment method discovery works:

Practical Example: Cart Page Widget

Performance Optimizations

1. Caching Strategy
2. Validation Short-circuits
3. Context-aware Responses

Webhook API Layer

The WebhookAPI layer in the SeQura integration-core library handles incoming webhook notifications from SeQura to synchronize order status changes with the platform. This is a critical component for maintaining data consistency between SeQura's system and the merchant's platform when payment statuses change.

Overview

The WebhookAPI follows a simplified Controller pattern with validation, handling, and asynchronous processing to ensure reliable webhook processing even under high load or temporary system issues.

Core Components

1. WebhookAPI Main Class
2. WebhookController
3. WebhookValidator
4. WebhookHandler
5. OrderUpdateTask
6. Webhook Model

Webhook Processing Flow

Practical Example: Magento Webhook Endpoint

Here's a comprehensive example showing how the WebhookAPI is implemented in a Magento webhook endpoint:

Practical Example: Platform-Specific Order Update Service

The ShopOrderService interface must be implemented by each platform:

Webhook Security and Validation

Asynchronous Processing

Expected HTTP Response Codes

SeQura expects specific HTTP response codes:

Task Execution System

The Task Execution System is the backbone of the SeQura integration-core library's asynchronous processing capabilities. It handles background tasks like webhook processing, order reporting, and long-running operations that cannot be executed synchronously without impacting user experience.

Overview

The task system follows an Event-Driven Queue Architecture with reliable execution, retry mechanisms, and comprehensive monitoring. It's designed to handle high-volume operations while maintaining data consistency and system responsiveness.

Core Components

1. Task (Abstract Base Class)
2. QueueService
3. QueueItem
4. Priority System

Creating Custom Tasks

Here's how to create and implement custom tasks:

Using the Queue Service

Here's how to enqueue and manage tasks:

Task Monitoring and Health Checks

Key Benefits of the Task System

  1. Asynchronous Processing: Non-blocking operations improve user experience
  2. Reliability: Automatic retry mechanisms handle temporary failures
  3. Scalability: Queue-based processing handles high-volume operations
  4. Monitoring: Progress tracking and health monitoring capabilities
  5. Store Context: Proper multi-store isolation and context management
  6. Priority Management: Critical tasks (webhooks) get priority over background tasks
  7. Error Recovery: Failed tasks can be analyzed and retried
  8. Resource Management: Prevents system overload through controlled execution

Task Execution Best Practices

  1. Progress Reporting: Always call reportProgress() for long operations
  2. Alive Signals: Use reportAlive() in loops to prevent timeout
  3. Store Context: Capture store context in constructor, use in execution
  4. Error Handling: Distinguish between retryable and permanent failures
  5. Serialization: Ensure all task data is properly serializable
  6. Resource Cleanup: Clean up resources in failure/abort handlers
  7. Monitoring: Implement health checks for production systems

Usage Pattern

ORM & Data Persistence Layer

The ORM (Object-Relational Mapping) & Data Persistence Layer provides a platform-agnostic abstraction for storing and retrieving SeQura integration data. It enables the core library to work with different database systems while maintaining consistent data operations.

Overview

The ORM follows a Repository Pattern with Entity-based modeling and Query abstraction to provide database-independent data operations. Each platform implements repositories using their native database capabilities.

Core Components

1. Entity (Abstract Base Class)
2. RepositoryRegistry
3. RepositoryInterface
4. QueryFilter

Creating Custom Entities

Here's how to create custom entities for storing integration-specific data:

Implementing Platform-Specific Repositories

Each platform must implement repositories for entity persistence:

[!IMPORTANT]
Remember that you need to register your custom repositories during bootstrap

Using the ORM for Data Operations

Here's how to use the ORM system in your services:

Advanced Query Examples

Key Benefits of the ORM System

  1. Platform Independence: Same code works across different platforms
  2. Type Safety: Strongly-typed entities prevent data corruption
  3. Query Abstraction: Database-independent query building
  4. Repository Pattern: Clean separation of data access logic
  5. Store Context: Automatic multi-store data isolation
  6. Configuration-Driven: Schema defined in entity configuration
  7. Performance: Indexed queries and efficient data access
  8. Extensibility: Easy to add custom entities and repositories

ORM Best Practices

  1. Entity Design: Keep entities focused and cohesive
  2. Repository Implementation: Use platform-native optimizations
  3. Index Strategy: Add indexes for frequently queried fields
  4. Query Optimization: Use specific filters to avoid full table scans
  5. Data Migration: Plan for schema changes and data migration
  6. Store Context: Always consider multi-store implications
  7. Cleanup: Implement data retention policies for large tables

Usage Pattern

Multi-store Context Management

The Multi-store Context Management system ensures proper data isolation and operations across different stores, websites, or tenant environments. This is crucial for platforms that serve multiple merchants or store configurations from a single SeQura integration instance.

Overview

The multi-store system follows a Context Switching Pattern with automatic store isolation to ensure that operations, configurations, and data access are properly scoped to the correct store context without manual intervention.

Core Components

1. StoreContext (Singleton)
2. Store Context Aspect

Understanding Store Context

Store context ensures that:

Store Context Usage Patterns

Here's how to properly manage store context in different scenarios:

Store-Aware Repository Implementation

Repositories automatically handle store context filtering:

Task Execution with Store Context

Background tasks maintain store context throughout execution:

Configuration Per Store

Store-specific configuration management:

API Context Integration

The AdminAPI, CheckoutAPI, and WebhookAPI automatically handle store context:

Key Benefits of Multi-store Context

  1. Automatic Data Isolation: Data is automatically filtered by store
  2. Configuration Separation: Each store has independent settings
  3. Credential Management: API calls use correct store credentials
  4. Task Context Preservation: Background tasks maintain store context
  5. Error Isolation: Issues in one store don't affect others
  6. Scalability: Easy to add new stores without code changes
  7. Security: Prevents data leakage between stores

Multi-store Best Practices

  1. Always Use Context: Never skip store context for multi-store operations
  2. Context Validation: Verify store context is set before operations
  3. Error Handling: Handle store-specific errors gracefully
  4. Performance: Batch operations by store when possible
  5. Monitoring: Track operations per store for monitoring
  6. Testing: Test with multiple store contexts
  7. Migration: Plan for store data migration scenarios

Usage Pattern

Configuration Webhook API Layer

The Configuration WebhookAPI layer in the SeQura integration-core library handles incoming webhook notifications from SeQura to synchronize all integration settings from Merchant portal, allowing faster support and removing the need to grant seQura integrators access to their e-commerce platform.

Overview

The Configuration WebhookAPI follows a simplified Controller pattern with validation, handling, and configuration synchronization to ensure reliable webhook processing even under high load or temporary system issues.

Core Components

1. Configuration WebhookAPI Main Class
2. ConfigurationWebhookController
3. ConfigurationWebhookValidationService

4. TopicHandlerRegistry

Webhook Processing Flow

SeQura API Proxy Layer

The SeQura API Proxy Layer provides a robust, authenticated communication layer between the integration and SeQura's APIs. It handles authentication, request formatting, response parsing, and error management for all SeQura API interactions.

Overview

The API proxy system follows a Proxy Pattern with Factory-based authentication and HTTP abstraction to provide reliable, secure communication with SeQura's services while abstracting the complexity of API authentication and request management.

Core Components

1. BaseProxy
2. AuthorizedProxy
3. AuthorizedProxyFactory
4. Specialized Proxies

API Proxy Implementation

Here's how to implement and use the SeQura API proxy system:

Proxy Factory Implementation

Custom factory for creating authenticated proxies:

Error Handling and Retry Logic

Robust error handling for API communication:

API Monitoring and Health Checks

Monitor API health and performance:

Key Benefits of the API Proxy Layer

  1. Authentication Management: Automatic credential handling and token generation
  2. Environment Abstraction: Seamless sandbox/live environment switching
  3. Error Handling: Comprehensive error catching and retry logic
  4. Request/Response Formatting: Automatic data transformation
  5. Security: Secure credential storage and transmission
  6. Monitoring: Built-in performance and health monitoring
  7. Extensibility: Easy to add new API endpoints and features
  8. Reliability: Retry mechanisms and graceful degradation

API Proxy Best Practices

  1. Error Handling: Always handle API exceptions appropriately
  2. Retry Logic: Implement exponential backoff for transient errors
  3. Caching: Cache proxy instances and responses when appropriate
  4. Monitoring: Track API performance and error rates
  5. Security: Never log sensitive authentication data
  6. Environment Management: Use correct environment for each operation
  7. Rate Limiting: Respect API rate limits and implement throttling

Usage Pattern

🧩 Customization and Extensibility

The Customization and Extensibility system allows developers to extend, modify, and customize the SeQura integration-core library to meet specific platform requirements, business logic, and integration scenarios. This section provides comprehensive examples of how to extend the core library for your specific e-commerce platform.

Extension Architecture Overview

The integration-core follows SOLID principles and uses dependency injection patterns that make it highly extensible through:

Core Extension Points

The library provides several key extension points where developers can inject custom functionality:

  1. Service Implementations: Custom business logic services
  2. Repository Implementations: Platform-specific data persistence
  3. Event Handlers: Custom responses to integration events
  4. API Transformers: Custom data transformation logic
  5. Configuration Providers: Platform-specific configuration
  6. Task Implementations: Custom background processing
  7. Proxy Extensions: Custom API communication patterns

Service Registration and Custom Implementations

To extend and override core services, you can register custom implementations in your Bootstrap after calling the parent method and using the same identifier in the BootstrapComponent.

Example of registering a custom service:

All versions of integration-core with dependencies

PHP Build Version
Package Version
Requires php Version >=7.2
ext-json Version *
ext-ctype Version *
ext-mbstring Version *
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package sequra/integration-core contains the following files

Loading the files please wait ...