Update branch master with new SDK version 3.0.0

.github/workflows/ci-master.yml

@@ -0,0 +1,26 @@
+name: CI master V3
+
+on:
+  push:
+    branches: [ "master" ]
+  pull_request:
+    branches: [ "master" ]
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v2
+
+      - name: Setup PHP
+        uses: shivammathur/setup-php@v2
+        with:
+          php-version: '8.2'
+
+      - name: Install dependencies
+        run: composer install
+
+      - name: Run unit tests
+        run: vendor/bin/phpunit --testsuite "Unit Tests"

.gitignore

@@ -1,22 +1,7 @@
-#SOs
-Thumbs.db
-*~
-._*
 .DS_Store
-
-#IDEs
-nbproject
-/.idea
-
-#Vagrant
-/.vagrant
-/Vagrantfile.local
-
-#Project
-/vendor
-/composer.lock
-
-#Samples Vendor
-/samples/vendor
-
-.env
+/vendor/
+.phpunit.cache
+.php-cs-fixer.cache
+.phpunit.result.cache
+.vscode
+.php-cs-fixer.cache

.pre-commit-config.yaml

@@ -0,0 +1,18 @@
+repos:
+- repo: https://github.com/pre-commit/pre-commit-hooks
+  rev: v3.2.0
+  hooks:
+  - id: trailing-whitespace
+  - id: end-of-file-fixer
+  - id: check-yaml
+  - id: check-added-large-files
+- repo: https://github.com/digitalpulp/pre-commit-php.git
+  rev: 1.4.0
+  hooks:
+  - id: php-lint
+  - id: php-lint-all
+  - id: php-cs
+    files: \.(php)$
+    args: [--standard=PSR1 -p]
+  - id: php-cs-fixer
+    files: \.(php)$

CODING_GUIDELINES.md

@@ -0,0 +1,104 @@
+# Coding Guidelines
+
+The Mercado Pago PHP SDK is a collaborative effort from the start. The SDK team thinks that contributions from
+different developer will enrich its feature set and make it more relevant to the community.
+
+However, absorbing all contributions as-is, while expedient, might lead to difficulties in maintenance of the codebase
+is left unchecked. A collaborative codebase often establish guidelines for contributors to ensure code remains
+maintainable over time. The effort to maintain the SDK is no different in this regard, so a bit of guidance is in order.
+
+The purpose of this guide is to set a baseline for contributions. These guidelines are not intended to limit the tools
+at your disposal nor to rewire the way you think but rather to encourage good neighbor behavior.
+
+## Language Guidelines
+
+We use **english** language. This is to be consistent everywhere, and to be considerate with developers that do not
+speak our native language.
+
+Therefore: source code, comments, documentation, commit messages, review comments, and any other kind of contribution *
+MUST* use english language.
+
+Typos are unavoidable, but try to reduce them by using a spellchecker. Most IDEs can be configured to run one
+automatically.
+
+## Code Guidelines
+
+To contribute to the project you need to have installed in your machine [pre-commit tool](https://pre-commit.com/) to
+check the code style and formatting.
+
+1. To check if pre-commit is installed, you must run the command below successfully:
+
+```
+$ pre-commit --version
+pre-commit 2.17.0
+```
+
+2. After pre-commit is installed at your machine, inside the SDK project folder, you must run the command below to set
+   up the git hook scripts of the project:
+
+```
+$ pre-commit install
+```
+
+After that, git hooks will run automatically before every commit command.
+
+Generally speaking, be conscious when contributing and try following the same style that the code in the SDK already
+has. If you have any doubts, just ask us!
+
+This rules will be enforced automatically when making a pull requests, and checks will fail if you do not follow them,
+resulting in your contribution being automatically rejected until fixed.
+
+## Comment Guidelines
+
+Comments in code are a hard thing to write, not because the words are difficult to produce but because it is hard to
+make relevant comments. Too much of it and people do not read comments (and it obfuscates code reading) and too little
+of it gives you no recourse but to read large portions of codebase to get insight as to what a feature/codeblock is
+doing. Both situations are undesirable and efforts should be made at all time to have a please comment reading
+experience
+
+As a general rule you would have to comment on decisions you made while coding that are not part of any specification.
+
+In particular, you should always comment any decision that:
+
+* Departs from common wisdom or convention (The **why's** are necessary).
+* Takes a significant amount of time to produce. A good rule of thumb here is that if you spent more than 1 hour
+  thinking on how to produce a fragment of code that took 2 minutes of wrist time to write you should document your
+  thinking to aid reader and allow for validation.
+* Need to preserve properties of the implementation. This is the case of performance sensitive portions of the codebase, implementations of security primitives, congestion control algorithms, etc.
+
+As a general rule of what not to comment you should avoid:
+
+* Commenting on structure of programs that is already part of a convention, specified or otherwise.
+* Having pedantic explanations of behavior that can be found by immediate examination of the surrounding code artifacts.
+* Commenting on behavior you cannot attest.
+
+### Branching Guidelines
+
+Currently `master` is our only long term branch, below a few suggestions of short term branches naming:
+
+* `hotfix/something-needs-fix`: Small routine patches in code to feature already there.
+* `feature/something-new`: A new feature or a change in an existent feature. Beware of breaking changes that would
+  require a major version bump.
+* `doc/improves-documentation-for-this-feature`: If you add or change documentation with no impact to the source code.
+
+### Git Guidelines
+
+All commits **SHOULD** follow the [seven rules of a great Git commit message](https://chris.beams.io/posts/git-commit):
+
+1. Separate subject from body with a blank line.
+2. Limit the subject line to 72 characters.
+3. Capitalize the subject line.
+4. Do not end the subject line with a period.
+5. Use the imperative mood in the subject line.
+6. Wrap the body at 72 characters.
+7. Use the body to explain what and why vs. how.
+
+Commits such as "fix tests", "now it's working", and many other common messages we find usually in code **WON'T** be
+accepted.
+
+Ideally we would like to enforce these rules, but we are realistic and understand that it might be a big change for some
+people. So unless deviating heavily from what was stated we might accept your commits even if not following these rules
+perfectly.
+
+Please avoid taking too much time to deliver code, and always [rebase](https://git-scm.com/docs/git-rebase) your code to
+avoid reverse merge commits.

CONTRIBUTING.md

@@ -0,0 +1,79 @@
+# Contributing to the Mercado Pago PHP SDK
+
+Thank you for your interest in contributing to the Mercado Pago PHP SDK!
+
+## How to contribute
+
+In order to contribute to the Mercado Pago PHP SDK effectively we provide guidelines to address common case for
+contributions. Presently we have guides for the following type of changes.
+
+* Request For Change (RFC) / Feature Request: These are suggestions / requests for features the SDK currently does not
+  have. The SDK team evaluates these requests for adequacy / relevance / capacity and overall architectural consistency.
+* Bug Reports: These are reports of noncompliance behavior with the SDK specification and other blatantly wrong behavior of the Mercado Pago PHP SDK.
+
+In addition to contributing in the form of Bug Reports and RFCs it is also possible to contribute directly in code with
+a Pull Request (PR). In the case of a Pull Request you should also indicate the nature of the Pull Request (
+Feature/Bug/etc.) to help the team asses the Pull Request. If you are enthusiastic about a particular Feature being
+added or a bug being fixed, a PR is often the quickest way to promote your change as the team does not have to allocate
+as many resources to process the contribution.
+
+In the case of PRs it is often best to consult with the SDK team before embarking on a PR, specially if it's a beefy
+one. Spending time on a PR that might later be rejected because major discrepancies with vision or competing
+contributions is an uncomfortable outcome for all involved people. Remember the SDK team with privilege overall
+consistency and progress over any one particular contribution.
+
+## Coding Guidance
+
+All contributions *MUST* follow the [Coding Guidelines](CODING_GUIDELINES.md). Contributions that fail to follow these
+guidelines will be disregarded and told to make the required modifications to do so.
+
+## Request For Change / Feature Request
+
+Generally speaking an RFC is needed when you want to add a new feature or change an existing one in an incompatible way
+that might result in a major version bump to the SDK.
+
+Though it seems a little bureaucratic, the process is in place in order to avoid frustration of a potential contributor
+by making the discussions take place before any code is written. Once the design and direction is fully agreed then the
+contributor can work peacefully knowing that their change will be committed.
+
+Please prepend your issue title with `[RFC]` so that's easier to filter.
+
+## Bug Reports
+
+Bugs are a reality in software. We can't fix what we don't know about, so please report liberally. If you're not sure if
+something is a bug or not, feel free to file it anyway.
+
+Before reporting a bug, please search existing issues and pull requests, as it's possible that someone else has already
+reported your error. In the off case that you find your issue as fixed/closed, please add a reference to it on your new
+one.
+
+Your issue should contain a title and a clear description of the issue. You should also include as much relevant
+information as possible, and a code sample that demonstrates the issue. The goal of a bug report is to make it easy for
+yourself - and others - to replicate the bug and develop a fix.
+
+Opening an issue is as easy as
+following [this link](https://github.com/mercadopago/sdk-nodejs/issues/new?assignees=&labels=&template=bug_report.md) and
+filling out the given template.
+
+Bug reports may also be sent in the form of a [pull request](#pull-request) containing a failing test.
+
+## Pull Request
+
+First and foremost: Source code, documentation, commit messages, review comments, and any other kind of contribution
+must *MUST* follow the [Coding Guidelines](CODING_GUIDELINES.md).
+
+We use the "fork and pull"
+model [described here](https://help.github.com/articles/about-collaborative-development-models/), where contributors
+push changes to their personal fork and create pull requests to bring those changes into the source repository.
+
+Your basic steps to get going:
+
+* Fork the corresponding SDK repository and create a branch from master for the issue you are working on.
+* Commit as you go following our git conventions.
+* Include tests that cover all non-trivial code. The existing tests should provide a template on how to test the SDK correctly.
+* Make sure all test passes.
+* All code changes are expected to comply with the formatting style.
+* Push your commits to GitHub and create a pull request against the corresponding SDK component master branch.
+
+If taking too much time to deliver code, **always** [rebase](https://git-scm.com/docs/git-rebase) towards `master` before
+asking for a review, and avoid reverse merge commits.