- PHP 7.0+
Para utilizar este SDK, debes tener las siguientes extensiones de PHP instaladas:
- ext-curl
- ext-json
- ext-mbstring
Para usar el SDK en tu proyecto debes usar Composer (si no lo tienes instalado, puedes instalarlo acá), añadiendo el SDK como dependencia a tu proyecto:
"require": {
"transbank/transbank-sdk": "2.0-beta"
}
Luego debes correr
composer update
También puedes instalarlo directamente desde la consola:
composer require transbank/transbank-sdk:2.0-beta
Si es primera vez que usas composer en tu proyecto, se creará una carpeta vendor/
con el SDK y todo lo necesario.
Te recomendamos leer como funciona Composer, pero para comentar un punto importante, ahora asegúrate de que se incluye
el archivo vendor/autoload.php
en tu proyecto, idealmente al inicio de todo tu código.
Si tu proyecto ya usa composer, la librería ya estará disponible para ser usaada sin que tengas que hacer nada adicional.
Nota: Si usas un hosting compartido o un ambiente donde no tienes acceso para instalar Composer, no te preocupes: Puedes instalar composer en tu propio computador, instalar el paquete como se indica anteriormente, y luego subir por FTP, SSH o como sea, todos los archivos del proyecto. No es necesario tener instalado composer en el servidor. Solo es necesario que los archivos generados tras la instalación de composer si estén.
Puedes encontrar toda la documentación de cómo usar este SDK en el sitio https://www.transbankdevelopers.cl.
La documentación relevante para usar este SDK es:
- Primeros pasos con Webpay y Onepay.
- Documentación sobre ambientes, deberes del comercio, puesta en producción, etc.
También puedes encontrar:
- Documentación general sobre los productos y sus diferencias: Webpay y Onepay.
- Referencia detallada sobre Webpay y Onepay.
- Para los commits respetamos las siguientes normas: https://chris.beams.io/posts/git-commit/
- Usamos ingles, para los mensajes de commit.
- Se pueden usar tokens como WIP, en el subject de un commit, separando el token con
:
, por ejemplo:WIP: This is a useful commit message
- Para los nombres de ramas también usamos ingles.
- Se asume, que una rama de feature no mezclada, es un feature no terminado.
- El nombre de las ramas va en minúsculas.
- Las palabras se separan con
-
. - Las ramas comienzan con alguno de los short lead tokens definidos, por ejemplo:
feat/tokens-configuration
- WIP = Trabajo en progreso.
- feat = Nuevos features
- chore = Tareas, que no son visibles al usuario.
- bug = Resolución de bugs.
Para ejecutar los test localmente debes ejecutar los siguientes comandos en una terminal.
make
Y luego ejecutar los test
make test
Para generar una nueva versión, se debe crear un PR (con un título "Prepare release X.Y.Z" con los valores que correspondan para X
, Y
y Z
). Se debe seguir el estándar semver para determinar si se incrementa el valor de X
(si hay cambios no retrocompatibles), Y
(para mejoras retrocompatibles) o Z
(si sólo hubo correcciones a bugs).
En ese PR deben incluirse los siguientes cambios:
- Modificar el archivo
CHANGELOG.md
para incluir una nueva entrada (al comienzo) paraX.Y.Z
que explique en español los cambios de cara al usuario del SDK. - Modificar este
README.md
para que los ejemplos usen la nueva versiónX.Y.Z
Luego de obtener aprobación del pull request, debe mezclarse a master e inmediatamente generar un release en GitHub con el tag X.Y.Z
. En la descripción del release debes poner lo mismo que agregaste al changelog.
Con eso Travis CI generará automáticamente una nueva versión de la librería y la publicará en Packagist.
Si descubres una falla de seguridad dentro de este proyecto, por favor, notifícanos por correo electrónico a [email protected]. Tomaremos el caso con la mayor celeridad.