v1 integration

Accounts coming from the previous platform can keep using their v1 integration without any change while e-Payouts keeps it enabled. For anything new, use API v2.

Migrated v1 accounts only. New accounts do not have the v1 integration and it is not enabled for them: they must integrate with v2 (paymentbox URL with module, or POST /v2/payments, and signed JSON notifications). Migrated accounts will be given a deadline to move to v2; on that date the v1 integration is turned off and everything on this page stops working for that account.

What keeps working the same

Piece	How it is used (same as v1)
Paymentbox	`https://paymentbox.e-payouts.com/?uid=…&mid=…&price=…&ucode=…` with the same parameters as always (uid, mid, price, ucode, pm, email/cemail, name/cname, cc, and localprice/lp for the local-currency price).
createCode	`POST https://api.e-payouts.com/createCode.php` with a form (uid, mid, apikey, type, email, price, ucode, cc, name, lastname, direct). The v1 apikey is required. Returns code, price, error and url.
getData	`GET https://api.e-payouts.com/getData.php?uid=…&mid=…&cc=…&apikey=…&price=…` with your v1 apikey and only from the IPs set on the module.
Notification to your server	GET to the module notification URL with `uid, mid, country, price, code, email, currency, result, ucode, type`. result=ok when the payment completes. Reply HTTP 200.
Return to your site	To the module success URL with code and ucode (plus pago and estado).

Example: createCode

HTTP

POST https://api.e-payouts.com/createCode.php
Content-Type: application/x-www-form-urlencoded

uid=1001&mid=5001&apikey=TU_APIKEY_V1&type=ppal&email=cliente%40example.com&price=15.50&cc=ES&ucode=PEDIDO-1001

Response

{"code":"K7Q2ZP9XW4RM","price":"15.50","error":0,"url":"https://paymentbox.e-payouts.com/pagar?t=…"}

With direct=1 it replies with the redirect to the paymentbox. The code is the one you later get in the notification and on the return to your site.

Example: notification to your server

HTTP

GET https://tu-sitio.com/notificacion.php?uid=1001&mid=5001&country=ES&price=15.500&code=K7Q2ZP9XW4RM&email=cliente%40example.com&currency=EUR&result=ok&ucode=PEDIDO-1001&type=ppal

As in v1, the notification is not signed in the URL. It also carries the X-Epayouts-Signature header (HMAC of the full URL with your webhook signing key): verify it if you can. If your server does not reply 200, it is retried.

Error codes

As in v1: always HTTP 200 with {"error": …}.

createCode	Meaning
1	type (method) missing
2	email missing
3	invalid uid
4	invalid mid
5	mid not found or from another merchant
6	uid not found
7	account disabled or v1 integration not enabled
8	invalid price
10	method not available for that module, country or amount
17	too many attempts, retry in a minute
18	apikey missing
19	site or module not enabled
20	wrong apikey

getData	Meaning
5	mid not found or from another merchant
6	uid not found or account disabled
19	site not enabled
22	wrong apikey
30	IP not allowed in the module, or v1 integration not enabled
31	no methods available for that country and amount
32	cc (country) invalid or missing

As in v1, createCode returns some errors as text with a leading zero ("01", "05", "17") and others as numbers (18, 20): compare the value as a number, not as text.

getData without uid, mid or apikey returns an empty response, as in v1.

Moving to v2

Paymentbox: replace uid+mid with modulo (the module id shown in your merchant panel → Integration code). Paymentbox →
API: POST /v2/payments with the signed headers, instead of createCode and getData. Authentication →
Notifications: your server starts receiving signed JSON POSTs. Webhooks →
Optional intermediate step: the routes https://api.e-payouts.com/v1/createCode and /v1/getData accept v1 parameters with the signed v2 headers. They also stop working when the v1 integration is turned off.