If you use Stripe, payment and renewal information appears on your sales screen.
The amount, date and currency of the payment record in Stripe are carried into the customer card as fields via the REST API; the subscription renewal date enters the sales pipeline as an opportunity. We build the connection ourselves, as a project whose scope is determined during discovery. The payment adapters defined in the product: iyzico and PayNkolay.
A company that asks about Stripe is really asking three things
The Stripe question may come from companies that sell abroad and work with recurring revenue: software, agencies, training, subscription services. The question is not “do you have a Stripe logo”; underneath it sit three real needs:
- “Has the customer paid?” When a rep goes into a renewal conversation, they do not know whether the payment went through; they have no access to the Stripe dashboard either, and it would not be right for them to have it.
- “When does the subscription end?” The renewal date may be sitting in an Excel file or in one person's calendar. The mechanism is this: if the date is not tied to a record, there is nothing to warn anyone when it is missed.
- “Who will hear about a failed payment?” Word of the customer whose card was declined stays on the finance side; sales finds out at the end of the month.
Then there is the foreign-currency side: the price is in dollars or euros, the books are in Turkish Lira. The question of “how much this customer brought in” changes depending on which day's exchange rate is used.
None of these three questions is solved under the heading “Stripe integration”. All three are solved by carrying information that has already formed in Stripe onto the sales screen.
The honest picture first: what is and is not in the product
We do not have a Stripe connection and there is no subscription/billing engine inside the product; if you want to carry the payment record in Stripe into the CRM, that is a piece of work with a defined scope, over the REST API.
Let us make that concrete, because we measured it: the only thing written for Stripe in the code base is a “later on” note — there is no working connection, no adapter and no configuration screen. In the same way, the subscription, recurring billing and credit-card collection model is not defined in the product either.
Saying what really is defined is our job: there are two payment adapters in the product — iyzico and PayNkolay. They are configured with your own provider account. But we do not overstate here either: we cannot point to a live collection flow with a reference today, so we do not say “we take payments in production”. If you collect payments in Turkey, the right question is not “is it Stripe”, but “does one of these two adapters do the job for you”.
What remains — and what really can be built — is this: the visibility of the payment record. Payment, subscription and renewal information formed in Stripe comes into the CRM as fields, via the REST API or a periodic import. The interface is ready: the product ships out of the box with 183 business objects and each one is published in the REST API with its own data and schema endpoint — you can read the field structure from outside with describe. Alongside it there are OAuth2, signed outgoing webhooks and a four-step import/export wizard. As a separate fact: in one live customer installation today, a third-party ERP integrator reads and writes records over the same REST API; this is a single installation, not a list of cases. The general framework is on the integrations page.
Tuesday 10:30 — the annual subscription ends in twelve days and nobody knows. Here is what changes when the payment record flows into the CRM:
-
1
The renewal date becomes an opportunity in the sales pipeline
The subscription end date sits on the customer card as a field and upcoming renewals are opened as opportunities. The renewal is tied to the sales pipeline, not to anyone's calendar.
-
2
The rep sees whether the payment went through, on their own screen
The amount, date and status of the last payment are written onto the customer card. The rep does not need access to the Stripe dashboard — not having it is the more correct arrangement anyway.
-
3
A failed payment opens a task
When a payment comes back failed, a follow-up task lands on the owner. The customer whose card was declined is reached the same day; it does not wait for the month-end report.
-
4
Foreign-currency amounts are reported at a single rate
The product is multi-currency and works with the daily TCMB rate; on the day of measurement, 21-23 currencies were up to date in eight of eight tenants. Dollar collections are totalled in a single currency in the report.
-
5
The customer's real value comes together on one card
The quote, the won opportunity and the amount collected are tied to the same record. The question “what did this customer bring in” is answered without merging two tables.
-
6
A customer whose subscription ends does not disappear
The reason for cancellation or non-renewal is recorded as a loss reason. How many customers left for which reason is read from a report, not talked about by guesswork.
We do not have a Stripe connection — what do we do instead?
Carrying the payment record onto the customer card
Amount, date, currency and payment status come into the CRM as fields, via the REST API or a periodic import. The authority over the money stays in Stripe; the copy in the CRM is there for the sales team to see.
Turning the renewal date into an opportunity
The subscription end date is held as a field; an opportunity is opened for upcoming renewals and an owner is assigned. This is not a billing engine — it is follow-up on the sales side.
Task generation on a failed payment
The rule that opens a task for the owner when failed or overdue payment information arrives is defined during setup. The CRM does not charge the card again and does not attempt collection; it only ties the follow-up to a record.
Multi-currency reporting
The system is multi-currency and works with the daily TCMB rate. Dollar and euro collections are reported in a single currency; 21-23 currencies were measured as up to date in eight of eight tenants.
Pointing you to the two adapters that really are defined
If you collect payments in Turkey, there are two adapters defined in the product: iyzico and PayNkolay. They are configured with your own provider account; going live is done together, within the scope of the setup.
Defining subscription fields without writing code
An administrator adds fields such as plan name, seat count, renewal date and payment method without writing code. Adding custom fields is standard in the product: today 277 custom fields in total are defined across 19 tenants.
What exists and what does not on the payment and subscription side
| What is wanted | In Rapitek CRM | Where it is done |
|---|---|---|
| A built-in connection from your Stripe account to the product | No. There is no working connection for Stripe in the code base | In your Stripe account; carrying it into the CRM is built with the REST API, within a project scope |
| A subscription and recurring billing engine inside the product | No. The subscription, invoice and payment model is not defined in the product | In Stripe or in whichever billing system you use |
| The CRM charging the customer's card | No. Storing cards and attempting collection is not the product's job | In your payment provider |
| The payment amount, date and status being visible on the customer card | Yes. It is carried as fields via the REST API or a periodic import | Rapitek CRM — with a connection whose scope is determined during discovery |
| Tracking the renewal date and opening an opportunity | Yes. The field, the opportunity and task generation are defined during setup | Rapitek CRM |
| Taking payments through a payment adapter | Partly. The iyzico and PayNkolay adapters are defined in the product; we cannot point to a live collection flow with a reference today | Rapitek CRM — with your own iyzico or PayNkolay account, within the setup scope |
| Reporting foreign-currency collections at a single rate | Yes. Multi-currency and the daily TCMB rate work in the product | Rapitek CRM |
| Issuing an e-Invoice after the payment | No. Rapitek CRM is not a GİB private integrator and does not issue official documents | In your e-Invoice provider; the information can be carried into the CRM |
How is payment visibility put into service?
-
1
Discovery
We work out which objects you use in Stripe — one-off payments, subscriptions or invoices — and which record they will correspond to in the CRM. We recommend that your finance lead join this meeting.
-
2
Scope, field mapping and direction
Which field flows in which direction and how often is written down. This flow is built one-way — from Stripe to the CRM. We do not recommend the CRM writing back to Stripe; the authority over the money stays in one place.
-
3
Configuration and test transfer
Subscription and payment fields, renewal opportunity rules and permissions are set up; a test transfer is run with sample data. Customer matching — email or tax number — is verified here.
-
4
Training and go-live
The sales team is walked through which field shows what. We do not commit to a duration before discovery; after the discovery meeting we give you a date, not a range.
Our limits: what we do not promise on this page
This page already opened with an absence; let us set the limits out together again so that no item is left in a footnote.
- We do not say “Stripe integration”. There is no working connection for Stripe in the code base.
- We do not promise credit-card subscriptions and automatic billing. The subscription, invoice and payment model is not defined in the product; the CRM does not store cards and does not attempt collection.
- We do not say “we take payments in production”. The iyzico and PayNkolay adapters are defined in the product, but we cannot point to a live collection flow with a reference today.
- We do not say that the order → invoice → collection chain will flow by itself, we do not promise stock synchronisation and we do not promise production/MRP automation. We have written the reason for all three, and what can be done instead, in one place: the three things we do not promise.
- We do not issue e-Invoices. Rapitek CRM is not a GİB private integrator; the details are on our e-Invoice page.
Data location: your data is held in the European Union — the database in Helsinki (Finland), files in Frankfurt, backups in Falkenstein (Germany). We have no component in Turkey and we have no such feature as region selection. This is a transfer abroad under KVKK art. 9; we establish your legal basis for the transfer together during the contract process. The details are on the security page and in the KVKK disclosure notice.
Card data: no card number or card data is carried into the CRM — this is not a preference, it is a rule. What is carried is the result of the payment: amount, date, currency, status.
Certification: we do not have an ISO 27001 or SOC 2 certificate and we will not claim one until we do. We also do not do work that falls within PCI DSS scope, because card data never reaches us.
We put the number on the pricing page, not on this one
The scope of the Stripe connection, and its price if there is one, are worked out in the discovery meeting and shared in writing. Plan prices we keep in one place — so that you do not read a different number in two places.
Three plans, a scope table and separately priced items on one page.
Frequently asked questions about Stripe and Rapitek CRM
Does Rapitek CRM have a Stripe integration?
Is there a ready-made Stripe module in Rapitek CRM?
Is there subscription management in Rapitek CRM?
Can we take credit-card payments through the CRM?
Can we track Stripe subscription renewal dates in the CRM?
Does the CRM notify us when a payment fails?
Can we see dollar and euro collections in a single report?
We collect payments in Turkey; what do you recommend instead of Stripe?
Is card information carried into the CRM?
Do Stripe invoices count as e-Invoices in Turkey?
What does this connection cost?
Where is our data held?
Who does support come from?
Can we see this connection before buying?
Let's clarify your payment and renewal flow in 30 minutes
In the demo, let us talk through your own scenario: which payment provider you work with, who tracks renewals today, and which fields need to be carried into the CRM.
No card data is carried into the CRM. The scope, and the price if there is one, are worked out in discovery and shared in writing.
