Certification Process
What Is the Certification Process?
Before going live with your payment integration, you must complete a certification process to ensure your implementation meets GetNet’s technical, security, and user experience standards, as well as regulatory requirements. Once you have finalized the commercial agreements with GetNet’s sales team, the certification process begins when the GetNet integrations team contacts you to guide you through the technical validation. This process validates that your integration handles payments securely, provides a good user experience, and complies with industry best practices.
Step 1: Security Requirements
PCI DSS Certification
An active PCI DSS certificate is mandatory. This document must be obtained from the party responsible for capturing cardholder data—either your organization or a third-party provider. Once available, submit the certificate to the Integration Support Team for approval via email.
Sensitive Data Protection
Cardholder data must be handled with strict security measures:
- Never display the full card number at any point in the transaction flow
- Never store or display CVV data at any stage, including on transaction receipts
- On vouchers or receipts, only display the BIN and the last four digits of the card number
- Ensure all sensitive data is encrypted in transit and at rest
Step 2: User Interface Requirements
To ensure a seamless and transparent payment experience for your users, your integration must meet the following user interface requirements:
Payment Initiation and Branding
Before submitting a payment, display a clear and concise transaction summary to the user. Include appropriate payment gateway branding (such as the GetNet logo) depending on your integration context.
Terms and Conditions
Provide a clearly visible link allowing users to read and accept the terms and conditions before completing the payment.
Frequently Asked Questions (FAQ)
Include a section with frequently asked questions related to electronic payments. A suggested FAQ document is provided during the onboarding process.
Transaction History
Users must have access to a summary of their past purchases, which should include the following details:
- Reference number
- Date of the transaction
- Amount (including currency)
- Transaction status
Step 3: Technical Security Requirements
Your integration must implement technical security measures to protect sensitive data, prevent duplicate transactions, and ensure reliable payment processing. These requirements are essential for maintaining security compliance and providing a secure payment experience.
Secure Credential Storage
Credentials must be stored securely, either in a protected database with encryption or as environment variables. Secure configuration management systems may also be used. Under no circumstances should these credentials be exposed in source code, version control systems, or client-side code.
Payment Button Handling
To prevent accidental multiple charges, measures must be in place to avoid repeated submissions caused by double-clicking the payment button, network delays, or browser back/forward navigation issues.
Idempotency Control
The use of the idempotency_key field must be implemented to ensure that duplicate payment attempts are not processed more than once. This prevents accidental duplicate charges when network issues occur.
Handling of Pending Transactions
If a transaction remains in a pending state, the system must notify the user accordingly before allowing a new payment attempt to be initiated. Implement proper status tracking and user communication for pending transactions.
Step 4: Data Validation Requirements
Proper data validation ensures that payment information is collected accurately, securely, and in compliance with authentication requirements. Your integration must validate all input fields before submission and collect the necessary data for 3D Secure authentication when applicable.
Mandatory Fields for 3DS Authentication (if Applicable)
When implementing 3D Secure authentication, collect the following mandatory fields:
- Cardholder’s email address
- Full name
- Phone number
- IP address of the device used during the transaction
Recommended Fields for 3DS Authentication
To enhance security and improve authentication accuracy, also include billing address details:
- City
- Country
- Address line
- Postal code
- State
Luhn Algorithm and CVV Validation
Card numbers must be validated using the Luhn algorithm (a mathematical formula used to validate identification numbers, such as credit card numbers, IMEI numbers, Social Security numbers, and others). The CVV field should accept numeric input only and must be rendered as a password-type field to protect sensitive data.
Field Validation Rules
- First and last names: Must not contain special characters or numeric values
- Email addresses: Must adhere to a valid email format
- All required fields: Must be validated before submission
Step 5: Transaction Flow Testing
You must perform and document the following transaction scenarios:
| Transaction Type | What to Validate | Required Evidence |
|---|---|---|
| Approved / Accepted | Display status, message, description, date, total amount, and currency | Panel and frontend screenshots |
| Rejected / Denied / Error | Same data as for an approved transaction | Panel and frontend screenshots |
| Pending | Validate matching initial and final status | Evidence before and after status change |
Integration Logs
Maintain logs of all requests sent to the payment gateway. These logs are essential for troubleshooting, auditing, and validating your integration’s behavior.
Step 6: Additional Integrations
Webhook (Status Notifications)
You must expose 4 URLs during accreditation on the Digital Platform to receive asynchronous transaction status notifications. These webhooks enable real-time updates when transaction statuses change.
Probe / Cronjob
Implement a mechanism to handle pending transactions:
- Simulate a pending transaction.
- Manually update its status from the admin panel.
- Verify that your website automatically reflects the status change.
Step 7: Transaction Data Requirements
Your integration must include complete and accurate transaction data to ensure proper processing, compliance with regional requirements, and successful payment handling. This includes payer and buyer information, unique transaction references, and any required tax or payment modifier details.
Payer and Buyer Information
Include data for both payer and buyer entities in the transaction flow when applicable.
Unique Transaction Reference
Each transaction must have a unique reference identifier to prevent duplicates and enable proper tracking.
Tax Handling
Verify whether any of the available countries require taxes to be broken down separately in the transaction data.
Payment Modifiers
Validate that required fields are included based on the type of financing or applicable taxes for your market.
Step 8: Transaction Reversal
If your integration supports transaction reversals or cancellations, these operations must be properly implemented and validated during the certification process. This ensures that cancellation requests are handled correctly and that status updates are accurately reflected in your system.
Cancellation Process
If you have implemented transaction reversals via API, this flow must also be validated during certification. Ensure that cancellation requests are handled correctly and status updates are reflected in your system.
Validation Checklist
Throughout the certification process, you are required to provide evidence of compliance. This can be submitted via:
- Email documentation
- Screenshots demonstrating functionality
- Video recordings of user flows
- Integration logs
If any requirement is not implemented, you must provide a justification explaining why. All submitted information is reviewed and validated by the Quality Assurance and Information Security teams.
See Also
For information about PCI DSS compliance requirements, see PCI Compliance (PCI DSS). For details about secure data handling, see Tokenization. To understand authentication requirements, see 3DS Authentication 2.0.