This is a private Composer repository.
To use it, you have to add this repository to your composer.json file.
Add this Composer
repository to your project's composer.json
file, then you can require these private packages just like you would with
one from Packagist.
{
"repositories": [{
"type": "composer",
"url": "https://packagist.mavdev.eu"
}]
}
Read more on how to handle composer private packages.
PHP5 Database ORM
Fork of symfony 1.4 with dic, form enhancements, latest swiftmailer and better performance
The Messaging API allows services to send messages (SMS) via one of the support message providers, through a preference mechanism, such that when the first service fails the second is tried and the default failure message is send to teams. This API offers functionality in a CQRS like approach to distinguish mutable from unmutable operations. Message Sending Operations will not necessarily be executed at instantly - the operations will not return a direct operation result. The client has the responsibility to inject a unqiue operation reference identifier and lookup the actual operation result in the system. All operations ## Authentication This API uses API Key authentication for service to service communication ## Services offered - Send SMS - Retrieve status of SMS sent - Send Email - Retrieve the status if the sent email ## Correlation Handling Every request MUST pass in a unique identifier to be used for request correlation in the system. Uses the ULID format (a time-based, sortable UUID). Note this will need to be *different* for every request. ## Status codes This API uses HTTP status codes to communicate with the API consumer. + `200 OK` - Response to a successful GET, PUT, PATCH or DELETE. + `201 Created` - Response to a POST that results in a creation. + `202 Accepted` - The request has been accepted for processing, but the processing has not been completed. + `204 No Content` - Response to a successful request that won't be returning a body (like a DELETE request). + `302 Found` - Tells the customer to look at (browse to) another url. + `304 Not Modified` - Response has not been modified since the previous transmission. + `400 Bad Request` - Malformed request; request body validation errors. + `401 Unauthorized` - When no or invalid authentication details are provided. + `403 Forbidden` - When authentication succeeded but authenticated user doesn't have access to the resource. + `404 Not Found` - When a non-existent resource is requested. + `405 Method Not Allowed` - Method not allowed. + `409 Conflict` - When the request could not be completed due to a conflict with the current state of the resource + `422 Unprocessable Entity` - The request was well-formed but was unable to be followed due to semantic errors. + `500 Server Error` - Something went wrong on the API end. + `501 Not Implemented` - The server either does not recognize the request method, or it lacks the ability to fulfill the request. ## Encoding Every string passed to and from the API needs to be UTF-8 encoded. For maximum compatibility, normalize to Unicode Normalization Form C (NFC) before UTF-8 encoding. ## Representation of dates and times All exchange of date and time-related data MUST be done according to ISO 8601 standard and stored in UTC. All dates in the API are strings in the following format: `YYYY-MM-DDThh:mm:ss.SSSZ`. ## Media Type Where applicable this API uses the JSON media-type. Requests with a message-body are using plain JSON to set or update resource states. A special media-type is used for binary data exchange. The API accepts JSON in request bodies and requires that the `Content-type: application/json` header be specified for all such requests. The API will always respond with a JSON object, unless stated otherwise. Depending on context, resources may be returned as single objects or as arrays of objects, nested within the response object. `Content-type: application/json` and `Accept: application/json` headers **should** be set on all requests if not stated otherwise. ## Usage - dependent on role and access level + Send an SMS to a specific number + Retrieve the status of an SMS + Send en email with
maviance KYC service API. This API can be used by various application for KYC data capture and validation. ## Authentication This API uses JWT token authentication (Bearer in HTTP Header). A valid token is required to connect to any endpoint. This API uses API Key authentication (Key in x-api-key HTTP Header). A valid Key is required to connect to any endpoint. ## Access control The JWT token shall contain information about - username - roles - agentId - companyId ## KYC services offered - Query existing KYC information on entities - Create new KYC entities - Process (validate) KYC ## Status codes This API uses HTTP status codes to communicate with the API consumer. + `200 OK` - Response to a successful GET, PUT, PATCH or DELETE. + `201 Created` - Response to a POST that results in a creation. + `202 Accepted` - The request has been accepted for processing, but the processing has not been completed. + `204 No Content` - Response to a successful request that won't be returning a body (like a DELETE request). + `302 Found` - Tells the client to look at (browse to) another url. + `304 Not Modified` - Response has not been modified since the previous transmission. + `400 Bad Request` - Malformed request; request body validation errors. + `401 Unauthorized` - When no or invalid authentication details are provided. + `403 Forbidden` - When authentication succeeded but authenticated user doesn't have access to the resource. + `404 Not Found` - When a non-existent resource is requested. + `405 Method Not Allowed` - Method not allowed. + `409 Conflict` - When the request could not be completed due to a conflict with the current state of the resource + `422 Unprocessable Entity` - The request was well-formed but was unable to be followed due to semantic errors. + `500 Server Error` - Something went wrong on the API end. + `501 Not Implemented` - The server either does not recognize the request method, or it lacks the ability to fulfill the request. ## Encoding Every string passed to and from the API needs to be UTF-8 encoded. For maximum compatibility, normalize to Unicode Normalization Form C (NFC) before UTF-8 encoding. ## Representation of dates and times All exchange of date and time-related data MUST be done according to ISO 8601 standard and stored in UTC. All dates in the API are strings in the following format: `YYYY-MM-DDThh:mm:ss.SSSZ`. ## Media Type Where applicable this API uses the JSON media-type. Requests with a message-body are using plain JSON to set or update resource states. A special media-type is used for binary data exchange. The API accepts JSON in request bodies and requires that the `Content-type: application/json` header be specified for all such requests. The API will always respond with a JSON object, unless stated otherwise. Depending on context, resources may be returned as single objects or as arrays of objects, nested within the response object. `Content-type: application/json` and `Accept: application/json` headers **should** be set on all requests if not stated otherwise. ## Usage - dependent on role and access level + Create entity + Create document in entity + Upload binary data for document + Process (reject/accept)
Logger processor for filtering sensitive information while logging API calls
Generic connector interface to use be used to streamline php implementations of Smobilpay services
The Payment Information API is a closed API to be used by Smobilpay internal clients to interact with the Smobilpay payment core to query payments performed on the platform. ## Authentication This API uses token authentication (Bearer in HTTP Header). A valid token is required to connect to any endpoint. ## Access control The JWT token shall contain information about - agentGid - companyGid ## Services offered The following services are accessible depending on user scope |Service|Global User|Tenant User| |---|---|---| |Retrieving post processing payment details for successful payments|YES|YES| ## Status codes This API uses HTTP status codes to communicate with the API consumer. + `200 OK` - Response to a successful GET, PUT, PATCH or DELETE. + `201 Created` - Response to a POST that results in a creation. + `202 Accepted` - The request has been accepted for processing, but the processing has not been completed. + `204 No Content` - Response to a successful request that won't be returning a body (like a DELETE request). + `302 Found` - Tells the client to look at (browse to) another url. + `304 Not Modified` - Response has not been modified since the previous transmission. + `400 Bad Request` - Malformed request; request body validation errors. + `401 Unauthorized` - When no or invalid authentication details are provided. + `403 Forbidden` - When authentication succeeded but authenticated user doesn't have access to the resource. + `404 Not Found` - When a non-existent resource is requested. + `405 Method Not Allowed` - Method not allowed. + `409 Conflict` - When the request could not be completed due to a conflict with the current state of the resource + `422 Unprocessable Entity` - The request was well-formed but was unable to be followed due to semantic errors. + `500 Server Error` - Something went wrong on the API end. + `501 Not Implemented` - The server either does not recognize the request method, or it lacks the ability to fulfill the request. ## Encoding Every string passed to and from the API needs to be UTF-8 encoded. For maximum compatibility, normalize to Unicode Normalization Form C (NFC) before UTF-8 encoding. ## Representation of dates and times All exchange of date and time-related data MUST be done according to ISO 8601 standard and stored in UTC. All dates in the API are strings in the following format: `YYYY-MM-DDThh:mm:ss.SSSZ`. ## Media Type Where applicable this API uses the JSON media-type. Requests with a message-body are using plain JSON to set or update resource states. A special media-type is used for binary data exchange. The API accepts JSON in request bodies and requires that the `Content-type: application/json` header be specified for all such requests. The API will always respond with a JSON object, unless stated otherwise. Depending on context, resources may be returned as single objects or as arrays of objects, nested within the response object. `Content-type: application/json` and `Accept: application/json` headers **should** be set on all requests if not stated otherwise.
Client library for the AIRTEL API
Client for bulksms SMS Gateway
Connector library to connect Smobilpay to a the CNPS exchange database for quick and dirty integration
LMT GoldSMS PHP Connector
PHP Nexttel Connector client
PHP Payway Integration API v3 Connector
Client library for the Talk360 API
PHP Vodafone SOAP EvoucherServiceAfrimax API Connector
maviance PHP Email Connector
Designed for creating xls reports based on PHPExcel
eTranzact Fundsgate PHP API Client library
FX currency conversion library
Client for GTS Infotel SMS HTTP Gateway
simple api client to talk to the job dispatcher service in oder to create jobs and get their status
PHP Smobilpay Manual Payment Connector
Client library for the MTN Mobile Money API
PHP Malawi Access Integration with Mob5G API
Universal PDF generator based on KNP Snappy using Twig
Generic library to calculate provision and the distribution to multiple stakeholders
Qlipay API Client - Extended Version
Client for qrcode service
API client for the agent payment api https://maviance.atlassian.net/wiki/spaces/SET/pages/2961539093/Agent+Payment+API
API client for the auth service api https://maviance.atlassian.net/wiki/spaces/SET/pages/1605108276/API
PHP connector client to connect to Smobilpay Standard Connector services of type BILL
PHP client to connect to Smobilpay Bulk Payment Service
Smobilpay Cash Out Connector Client for Cash out services
Smobilpay Core collection API
No description provided (generated by Openapi Generator https://github.com/openapitools/openapi-generator)
API client for the fx rate api https://maviance.atlassian.net/wiki/spaces/SET/pages/2963800065/FX+Rate+API
No description provided (generated by Openapi Generator https://github.com/openapitools/openapi-generator)
Smobilpay S3P API Client - PHP - Extended access to endpoints with more detailed information
API client for the service listing api https://maviance.atlassian.net/wiki/spaces/SET/pages/2961539159/Service+Listing+API
Generic SMPP Connector to send SMS
PHP connector client to connect to Smobilpay Standard Connector services of type TOPUP
No description provided (generated by Openapi Generator https://github.com/openapitools/openapi-generator)
Client for Telerivet SMS Gateway
Client for twilio SMS Gateway
PRL service Management API. This is a closed API can be used by the Shop BOM to endable and/or disable different PRL flow types, create links, manage customers, and products ## Authentication This API uses token authentication (Bearer in HTTP Header). A valid token is required to connect to any endpoint. ## Access control The JWT token shall contain information about - userID - roles - application ID ## PRL services offered - Manage products - Manage customers - Manage merchants - Generate PRL links - Query existing PRL information - Manage availability of different PRL flow types ## Status codes This API uses HTTP status codes to communicate with the API consumer. + `200 OK` - Response to a successful GET, PUT, PATCH or DELETE. + `201 Created` - Response to a POST that results in a creation. + `202 Accepted` - The request has been accepted for processing, but the processing has not been completed. + `204 No Content` - Response to a successful request that won't be returning a body (like a DELETE request). + `302 Found` - Tells the customer to look at (browse to) another url. + `304 Not Modified` - Response has not been modified since the previous transmission. + `400 Bad Request` - Malformed request; request body validation errors. + `401 Unauthorized` - When no or invalid authentication details are provided. + `403 Forbidden` - When authentication succeeded but authenticated user doesn't have access to the resource. + `404 Not Found` - When a non-existent resource is requested. + `405 Method Not Allowed` - Method not allowed. + `409 Conflict` - When the request could not be completed due to a conflict with the current state of the resource + `422 Unprocessable Entity` - The request was well-formed but was unable to be followed due to semantic errors. + `500 Server Error` - Something went wrong on the API end. + `501 Not Implemented` - The server either does not recognize the request method, or it lacks the ability to fulfill the request. ## Encoding Every string passed to and from the API needs to be UTF-8 encoded. For maximum compatibility, normalize to Unicode Normalization Form C (NFC) before UTF-8 encoding. ## Representation of dates and times All exchange of date and time-related data MUST be done according to ISO 8601 standard and stored in UTC. All dates in the API are strings in the following format: `YYYY-MM-DDThh:mm:ss.SSSZ`. ## Media Type Where applicable this API uses the JSON media-type. Requests with a message-body are using plain JSON to set or update resource states. A special media-type is used for binary data exchange. The API accepts JSON in request bodies and requires that the `Content-type: application/json` header be specified for all such requests. The API will always respond with a JSON object, unless stated otherwise. Depending on context, resources may be returned as single objects or as arrays of objects, nested within the response object. `Content-type: application/json` and `Accept: application/json` headers **should** be set on all requests if not stated otherwise. ## Usage - dependent on role and access level + CRUD functionality for PRL links + CRUD functionality for products + Enable/disable different PRL flows
Smobilpay Merchant REST API
Smobilpay Third Party (S3P) API client for PHP
Smobilpay service to store and resolve arbitrary customer names
The Float Management API is a closed API to be used by Smobilpay serivces to allow clients to trigger PAY IN and PAY OUT operations on Smobilpay float accounts (see Account and Float Management ). The need for a dedicated API for these operations is necessary in order to properly manage and track the addition and removal of float to Smobilpay accounts in accordance with Double-entry bookkeeping standards in contrast to the internal single-entry booking currently performed by the system for internal account movements between float accounts. The primary (but not limited to) use case is to provide these operations to PSS (Payment Settlement Service) in the scope of 1030 - Automating Smobilpay Customer Float Management The API handles all mutating account operations asynchronously - each operations will return a direct reservation id that clients can use to check the processing status. Clients also have the opportunity to inject a unqiue operation reference identifier to lookup the reservation id in case of network failure. ## Authentication This API uses token authentication (Bearer in HTTP Header). A valid token is required to connect to any endpoint. ## Access control The JWT token shall contain information about - roles ## Services offered - Get available mirror account configurations - Calculate the fees incured for payin or payout - Create, execute and finalize a payin request to credit float to a company account - Create, execute and finalize a payout request to debit float from a company account - Cancel a payin or payout request Access to the endpoints is also dependent on dedicated claims to be present in the JWT token |Domain|Description| |---|---| |floatmmt_config|Read access to access account configs| |floatmmt_read|Read access to requests| |floatmmt_createrequest|Permission to create a payin/payout request| |floatmmt_execute|Permission to execute a linked request operation| |floatmmt_confirm|Permission to confirm a linked request operation| |floatmmt_cancel|Permission to reject a registration| ## Correlation Handling Every request MUST pass in a unique identifier to be used for request correlation in the Smobilpay system. Uses the ULID format (a time-based, sortable UUID). Note this will need to be *different* for every request. ## Idempotence Every transaction request made will be idempontent in the context of the user making it using the injected external transaction id as a unique key. e.g. If a user sends the same request for payin / payout multiple times, only the first one will be processed as long as the extRefId remains identical. The system will return the current state of the record in the database and not create a new request ## Status codes This API uses HTTP status codes to communicate with the API consumer. + `200 OK` - Response to a successful GET, PUT, PATCH or DELETE. + `201 Created` - Response to a POST that results in a creation. + `202 Accepted` - The request has been accepted for processing, but the processing has not been completed. + `204 No Content` - Response to a successful request that won't be returning a body (like a DELETE request). + `302 Found` - Tells the customer to look at (browse to) another url. + `304 Not Modified` - Response has not been modified since the previous transmission. + `400 Bad Request` - Malformed request; request body validation errors. + `401 Unauthorized` - When no or invalid authentication details are provided. + `403 Forbidden` - When authentication succeeded but authenticated user doesn't have access to the resource. + `404 Not Found` - When a non-existent resource is requested. + `405 Method Not Allowed` - Method not allowed. + `409 Conflict` - When the request could not be completed due to a conflict with the current state of the resource + `422 Unprocessable Entity` - The request was well-formed but was unable to be followed due to semantic errors. + `500 Server Error` - Something went wrong on the API end. + `501 Not Implemented` - The server either does not recognize the request method, or it lacks the ability to fulfill the request. ## Encoding Every string passed to and from the API needs to be UTF-8 encoded. For maximum compatibility, normalize to Unicode Normalization Form C (NFC) before UTF-8 encoding. ## Representation of dates and times All exchange of date and time-related data MUST be done according to ISO 8601 standard and stored in UTC. All dates in the API are strings in the following format: `YYYY-MM-DDThh:mm:ss.SSSZ`. ## Media Type Where applicable this API uses the JSON media-type. Requests with a message-body are using plain JSON to set or update resource states. A special media-type is used for binary data exchange. The API accepts JSON in request bodies and requires that the `Content-type: application/json` header be specified for all such requests. The API will always respond with a JSON object, unless stated otherwise. Depending on context, resources may be returned as single objects or as arrays of objects, nested within the response object. `Content-type: application/json` and `Accept: application/json` headers **should** be set on all requests if not stated otherwise.
PHP connector client to interact with the Smobilpay MABS light service
PHP connector client to connect to Smobilpay Standard Connector services of type PRODUCT
No description provided (generated by Openapi Generator https://github.com/openapitools/openapi-generator)
Smobilpay S3P v.3.0.0 API Client for PHP
No description provided (generated by Openapi Generator https://github.com/openapitools/openapi-generator)
API Doc exposing some service connector feature endpoints
Generic interface to connect to sms providers
Smobilpay PAymenT connecTor sErvice fRamework
Fork of the sensio symfony 1.4 branch since it is now discontinued
This Composer repository is powered by Satis 1.0.0