---
title: "Kvalitetskrav ved app-gjennomgang | Tajo"
description: "Kravene til kvalitet, sikkerhet, UX og juss som Stripe-appen din må oppfylle for å bestå gjennomgangen"
url: https://tajo.io/no/docs/stripe-apps/review-requirements/
markdown: https://tajo.io/no/docs/stripe-apps/review-requirements.md
lang: no-NO
author: "Set Noa"
author_url: https://tajo.io/no/set-noa/
robots: noindex
---

Be om tidlig tilgang

Skriv inn fornavn og e-postadresse på jobb. Vi sender deg en lenke for å bekrefte forespørselen om tilgang til Tajo.

# Kvalitetskrav ved app-gjennomgang

[Set Noa](https://tajo.io/no/set-noa/)

Stripe går gjennom hver app som sendes inn til marketplace, opp mot et omfattende sett med kvalitetskrav. Setter du deg inn i disse kravene før du utvikler, sparer du tid og reduserer antall runder i gjennomgangen.

Caution

**Status: planlagt, ikke bygget.** Tajo har ingen Stripe-app, så ingenting i denne delen kan installeres i dag. App-identifikatorene, URL-ene og legitimasjonen på denne siden er illustrerende plassholdere, ikke ekte endepunkter.

## Oversikt

Gjennomgangen av Stripe-apper vurderer appen din på seks hovedområder:

1. **Transparent prising**, tydelig informasjon om kostnader
2. **Appfunksjonalitet**, pålitelighet og fullstendighet
3. **Utviklerstandarder**, kodekvalitet og bruk av API-et
4. **UX-kvalitet**, krav til grensesnitt og brukeropplevelse
5. **Sikkerhet**, databeskyttelse og sikre arbeidsmåter
6. **Juridisk etterlevelse**, personvern og regulatoriske krav

## Transparent prising

Appen din må informere brukerne tydelig om alle kostnader:

- **Åpen prising**: All prising må oppgis på forhånd i oppføringen i marketplace
- **Ingen skjulte gebyrer**: Brukerne må ikke møte uventede kostnader etter installasjon
- **Prøvevilkår**: Tilbyr du en prøveperiode, si tydelig hvor lenge den varer og hva som skjer når den er over
- **Oppgraderingsflyter**: Salgsfremstøt og oppgraderingsforslag må være diskré og tydelig frivillige
- **Valuta**: Vis prisene i brukerens lokale valuta når det er mulig

Caution

Apper som skjuler prisen eller belaster brukerne uten tydelig samtykke, blir avvist umiddelbart.

## Formatering av dato og klokkeslett

Alle datoer og klokkeslett appen din viser, må følge konvensjonene i Stripe Dashboard:

- Bruk brukerens lokalinnstilling for datoformat når den er tilgjengelig
- Vis klokkeslett i brukerens lokale tidssone
- Bruk relative tidsangivelser for nylige hendelser (for eksempel «2 timer siden»)
- Bruk absolutte tidsangivelser med full dato og klokkeslett for eldre hendelser
- Følg ISO 8601 for alle datofelt som går mot API-et

```typescript
// Good: Use Stripe's date formatting utilities
import { formatDate, formatRelativeTime } from '@stripe/ui-extension-sdk/utils';

const formattedDate = formatDate(timestamp); // Locale-aware
const relativeTime = formatRelativeTime(timestamp); // "2 hours ago"
```

## Appinnstillinger

Hvis appen din krever konfigurasjon:

- Lag en egen **innstillingsvisning** som er tilgjengelig fra appens viewport
- Fyll inn fornuftige standardverdier der det lar seg gjøre
- Valider alt brukerne skriver inn, med tydelige feilmeldinger
- La brukerne endre innstillinger uten å installere appen på nytt
- Ta vare på innstillingene mellom økter med Secret Store API i Stripe

## Støtte for sandkasse

Appen din må fungere riktig i Stripes sandkassemodus (testmodus):

- **Kompatibilitet med testmodus**: Alle funksjoner må fungere i testmodus
- **Testdata**: Bruk realistiske testdata som viser hva appen kan
- **Ingen live-data i sandkassen**: Eksponer aldri produksjonsdata i testmodus
- **Elegant håndtering**: Er en funksjon utilgjengelig i sandkassen, vis en tydelig melding om hvorfor
- Sett `sandbox_install_compatible: true` i manifestet ditt

```json
{
  "sandbox_install_compatible": true
}
```

## Appfunksjonalitet

### Pålitelighet

- Appen må ikke krasje eller henge under normal bruk
- Alle funksjoner du reklamerer for, må fungere som beskrevet
- Nettverksfeil må håndteres elegant, med mulighet for å prøve på nytt
- Appen må forbli responsiv mens den kjører operasjoner i bakgrunnen

### Fullstendighet

- Ingen plassholderinnhold, «kommer snart»-funksjoner eller ødelagte lenker
- Alle elementer i grensesnittet må fungere, ingen døde knapper eller inaktive kontroller
- Hjelpetekster og dokumentasjonslenker må peke til sider som finnes
- Avinstallering må fjerne alle appdata og webhooks på en ryddig måte

### Ytelse

- Grensesnittet må tegnes opp innen 3 sekunder på en vanlig tilkobling
- Synkronisering i bakgrunnen må ikke blokkere grensesnittet
- Store datamengder må bruke paginering eller lazy loading
- Hold antallet API-kall nede, slik at du unngår ratebegrensning

## Utviklerstandarder

### Bruk av API-et

- Bruk den nyeste stabile versjonen av Stripe API
- Følg beste praksis for Stripe API når det gjelder paginering, feilhåndtering og idempotens
- Ikke overskrid ratebegrensningene, bruk eksponentiell backoff ved nye forsøk
- Bruk webhooks for hendelsesdrevne oppdateringer i stedet for polling

### Kodekvalitet

- Ingen feil eller advarsler i konsollen i produksjonsbygg
- Fjern all feilsøkingslogging før du sender inn
- Håndter alle spesialtilfeller (tomme tilstander, manglende data, nettverksfeil)
- Følg mønstrene i Stripes komponentbibliotek for et konsistent grensesnitt

### Versjonering

- Bruk semantisk versjonering (MAJOR.MINOR.PATCH)
- Dokumenter bruddendringer i versjonsoppdateringene
- Behold bakoverkompatibilitet der det lar seg gjøre

## UX-kvalitet

### Reklame

- **Ingen annonser**: Appen din må ikke vise reklame av noe slag
- **Ingen kryssalg**: Ikke reklamer for andre produkter eller tjenester i appens grensesnitt
- **Merkevareinnhold**: Vis bare din egen merkevare, ikke tredjeparters (med unntak av integrasjonspartnere som Brevo)

### Språk og innhold

- **Konsistent språk**: Bruk samme terminologi gjennom hele appen
- **Profesjonell tone**: Match den profesjonelle, konsise kommunikasjonsstilen i Stripe Dashboard
- **Ingen sjargong**: Unngå teknisk sjargong som selgerne kanskje ikke forstår
- **Stavekontroll**: Sørg for at all tekst er fri for skrive- og grammatikkfeil
- **Kun engelsk**: All tekst brukerne ser, må være på engelsk i marketplace-apper

### Bekreftelsesdialoger

Krev at brukeren bekrefter destruktive eller viktige handlinger:

```typescript
// Good: Confirm before destructive actions
const handleDisconnect = async () => {
  const confirmed = await showConfirmation({
    title: 'Disconnect Brevo Integration',
    message: 'This will stop syncing customer data to Brevo. You can reconnect at any time.',
    confirmLabel: 'Disconnect',
    cancelLabel: 'Cancel',
    destructive: true,
  });

  if (confirmed) {
    await disconnectIntegration();
  }
};
```

Handlinger som krever bekreftelse:

- Koble fra integrasjoner
- Slette synkroniserte data
- Endre innstillinger som påvirker dataflyten
- Tilbakestille konfigurasjonen til standardverdier

### Lastetilstander

Vis alltid en lasteindikator for asynkrone operasjoner:

```typescript
// Good: Show loading state during data fetch
const CustomerSyncStatus = () => {
  const { data, isLoading, error } = useSyncStatus();

  if (isLoading) {
    return <Spinner label="Loading sync status..." />;
  }

  if (error) {
    return <Banner type="critical" title="Failed to load sync status">
      {error.message}
    </Banner>;
  }

  return <SyncStatusDisplay data={data} />;
};
```

Krav:

- Vis spinnere eller skjelettskjermer mens data lastes
- Deaktiver knapper mens et skjema sendes inn
- Vis fremdriftsindikatorer for operasjoner som tar lang tid
- Vis aldri en blank skjerm under lasting

### Feilmeldinger

Gi tydelige feilmeldinger brukeren kan handle på:

```typescript
// Bad: Generic error
"Something went wrong"

// Good: Specific and actionable
"Unable to sync customer data to Brevo. Please verify your Brevo API key
in Settings and try again."
```

Retningslinjer for feilmeldinger:

- Forklar hva som skjedde, i et enkelt språk
- Foreslå en konkret handling brukeren kan gjøre for å løse problemet
- Gi en måte å prøve den mislykkede operasjonen på nytt
- Logg detaljert feilinformasjon for feilsøking (som ikke vises til brukerne)
- Ta med feilkoder som support kan bruke, der det er relevant

## Sikkerhet

### Secret Store API

Bruk Stripes Secret Store API til all lagring av sensitive data:

```typescript
import { createHttpClient, STRIPE_API_KEY } from '@stripe/ui-extension-sdk/http_client';

// Good: Store secrets using the Secret Store API
const storeBrevoApiKey = async (apiKey: string) => {
  const stripe = createHttpClient(STRIPE_API_KEY);
  await stripe.apps.secrets.create({
    name: 'brevo_api_key',
    payload: apiKey,
    scope: { type: 'account' },
  });
};

// Good: Retrieve secrets from the Secret Store
const getBrevoApiKey = async () => {
  const stripe = createHttpClient(STRIPE_API_KEY);
  const secret = await stripe.apps.secrets.find({
    name: 'brevo_api_key',
    scope: { type: 'account' },
  });
  return secret.payload;
};
```

Lagre **aldri** sensitive data i:

- Local storage eller session storage
- Informasjonskapsler
- URL-parametere
- Hardkodede verdier i kildekoden
- Konfigurasjonsfiler i klartekst

### Kryptografi

- **Ingen egen kryptografi**: Ikke lag dine egne krypteringsalgoritmer
- Bruk de innebygde sikkerhetsprimitivene i Stripe (Secret Store, signeringshemmeligheter)
- Bruk HTTPS for alle eksterne API-kall
- Valider alle webhook-signaturer før du behandler dem

### Databehandling

- Be bare om tillatelsene appen din faktisk trenger
- Ikke lagre Stripe-data utover det funksjonaliteten krever
- Innfør retningslinjer for lagringstid som samsvarer med personvernerklæringen din
- Gi brukerne en måte å be om sletting av data på

## Juridisk etterlevelse

### Personvernerklæring

Appen din må ha en offentlig tilgjengelig personvernerklæring som dekker:

- Hvilke data appen din henter fra Stripe
- Hvordan dataene lagres, behandles og deles
- Retningslinjer for lagring og sletting av data
- Brukernes rettigheter til egne data
- Kontaktinformasjon for spørsmål om personvern
- Etterlevelse av gjeldende regelverk (GDPR, CCPA og lignende)

### Vilkår for bruk

- Lag tydelige vilkår for bruk av appen din
- Ikke ta med vilkår som er i strid med Stripes egne vilkår
- Si tydelig fra om eventuelle begrensninger i bruken

### Regulatorisk etterlevelse

- Etterlev alt gjeldende regelverk om databeskyttelse
- Innfør nødvendige databehandleravtaler
- Støtt forespørsler om dataportabilitet og sletting
- Før revisjonslogg over tilgang til og behandling av data

## Tidslinje for gjennomgangen

| Trinn | Varighet |
| --- | --- |
| Første innsending | 5-10 virkedager |
| Gjennomgang av revidert versjon | 3-7 virkedager |
| Endelig godkjenning | 1-2 virkedager |
| Publisering | Umiddelbart etter godkjenning |

Tip

Ta hånd om alle tilbakemeldingene fra gjennomgangen i én og samme revisjon, slik at du unngår flere runder. Stripe-teamet gir konkrete tilbakemeldinger du kan handle på, for hvert problem de finner.

## Vanlige grunner til avvisning

1. **Manglende feilhåndtering**, appen krasjer ved nettverksfeil eller uventede data
2. **For dårlige lastetilstander**, blanke skjermer mens data hentes
3. **Uklar prising**, prisen er ikke oppgitt fullt ut i oppføringen
4. **For mange tillatelser**, appen ber om tillatelser den ikke trenger
5. **Ødelagt sandkassemodus**, appen fungerer ikke i testmodus
6. **Sikkerhetsproblemer**, hemmeligheter lagres utenfor Secret Store API
7. **Manglende personvernerklæring**, ingen tilgjengelig URL til personvernerklæringen
8. **Ufullstendig funksjonalitet**, «kommer snart»-funksjoner eller plassholderinnhold