SDK Oficial de Transbank

• PHP 5.5+

En caso de instalar con Composer las siguientes dependencias deberían instalarse automaticamente, pero si usas el SDK de manera directa requerirás también:

• ext-curl
• ext-json
• ext-mbstring
• ext-soap

Para usar el SDK en tu proyecto puedes usar Composer, añadiendo el SDK como dependencia a tu proyecto:

    "require": {
        "transbank/transbank-sdk": "1.6.0"
    }

También puedes instalarlo desde la consola:

composer require transbank/transbank-sdk

O, si no deseas usar Composer, puedes descargar el código desde este repositorio y requerirlo directamente:

require_once('/directorio/del/sdk/init.php');

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:

• Documentación general sobre los productos y sus diferencias: Webpay y Onepay.
• Documentación sobre ambientes, deberes del comercio, puesta en producción, etc.
• Primeros pasos con Webpay y Onepay.
• Referencia detallada sobre Webpay y Onepay.

• Docker
• Make
• Plugin de editorconfig para tu editor favorito.

• 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 usar el siguiente comando en una terminal.

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) para X.Y.Z que explique en español los cambios de cara al usuario del SDK. Modificar el archivo composer.json para que la propiedad "version" apunte a la nueva versión X.Y.Z Modificar este README.md para que los ejemplos usen la nueva versión X.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.